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Section 


1 

Scope 


1.1  Identification 

This  document  is  the  final  technical  report  for  tiie  ComposabUity  for  Secure  Systems  program, 
contract  F30602-96-C-0344.  It  provides  an  overview  of  aU  of  the  technical  efforte  on  the 
program.  It  describes  significant  accomplishments  and  obstacles  encountered  during  these 
efforts  nnfl  lessons  learned  whole  carrying  out  the  program.  Finally,  it  provides  si^estions  for 
future  efforts  which  build  upon  the  successes  of  the  program  or  address  deficiencies. 


1 .2  Document  Overview 

The  report  is  structured  as  follows: 

■  Section  1,  Scope,  defines  the  scope  and  gives  this  overview  of  the  document, 

■  Section  2,  Program  Summary,  provides  a  high-level  summary  of  the  objectives,  ap¬ 
proach,  and  results  of  the  CSS  program, 

■  Section  3,  CSS  Framework,  describes  the  CSS  composition  and  refinement  framework, 

■  Section  4,  Top  Level  Specification,  describes  the  Top-Level  Specification  (TLS)  which 
models  network-transparent  IPC, 

■  Section  5,  Design  Refinement,  summarizes  the  refinement  of  the  network  server  com¬ 
ponent  of  the  TLS  into  an  ar-Kemel  network  stack, 

■  Section  6,  Fault  Tolerance,  describes  the  application  of  the  framework  to  the  specifica¬ 
tion  and  analysis  of  faxilt  tolerance  properties, 

■  Section  7,  Policy  Composition,  describes  the  modeling  of  restrictiveness  in  the  fi:ame- 
work  to  provide  for  composable  non-interference  analysis, 

■  Section  8,  Tool  Support,  describes  prototype  tools  to  support  the  application  of  the 
framework, 

■  Section  9,  Program  Conclusions,  summarizes  the  main  conclusions  of  the  CSS  program, 

■  Appendix  A,  Bibliography,  gives  citations  for  each  referenced  docmnent. 
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Section  ^ 

Program  Summary 


2.1  Objectives  and  Approach 

The  objective  of  the  Composability  for  Secure  Systems  (CSS)  program  was  to  develop  and 
demonstrate  a  composable  methodology  for  building  highly-assured,  secure,  fault-tolerant  dis¬ 
tributed  systems  and  networks,  and  design  an  automated  development  environment  to  support 
the  methodology. 

Many  kinds  of  system  properties  may  be  formally  einalyzed  diuing  a  system  design  effort 
including  functional  correctness,  fault  tolerance  and  security.  Substantial  work  has  been  done 
to  establish  effective  methods  for  performing  each  of  these  kinds  of  analysis.  However,  it  is 
typically  the  case  that  each  method  requires  a  particular  style  or  language  for  the  underlying 
formal  description  of  the  system.  This  is  unfortunate  for  two  reasons.  First,  there  can  be 
significant  expense  in  producing  multiple  specifications  of  a  system.  Second,  it  introduces  the 
question  of  whether  all  the  specifications  are  consistent,  and  it  makes  it  harder  to  determine 
whether  an  implementation  of  the  system  is  correct  since  it  must  be  compared  to  multiple 
formal  descriptions. 

To  address  these  issues  the  CSS  program  has  studied  composition  and  refinement  as  unifying 
concepts  that  support  analysis  of  functional  correctness,  fault  tolerance  and  security  (non¬ 
interference)  from  a  single  specification.  A  mathematical  friamework  has  been  developed  for 
specifying  and  analyzing  systems.  The  program  has  demonstrated  the  application  of  this 
framework  to  the  analysis  of  functional  correctness,  fault  tolerance  and  security. 


2.2  Significant  Results  and  Accomplishments 

The  following  list  highlights  the  major  results  and  accomplishments  of  the  program: 

■  Developed  a  framework  in  PVS  that  supports  composition  and  refinement  reasoning 
including  fairness  properties 

■  Used  the  framework  to  perform  a  proof-of-concept  analysis  of  fault  tolerance 

■  Formalized  the  restrictiveness  information  flow  policy  within  the  framework  and  proved 
that  this  formalization  is  composable 

■  Explored  the  development  of  tools  to  support  application  of  the  framework  including  a 
specification  browser  and  extensions  to  the  PVS  prover  to  make  it  easier  to  perform  proofs 
within  the  framework 

■  Specified  an  x-Kemel  protocol  stack  as  a  composition  of  components  within  the  framework 
and  used  the  framework  to  show  that  this  stack  is  a  refinement  of  an  abstract  network 
server  specification 
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2.3  Technical  Documentation 


There  are  four  primary  types  of  output  fium  the  CSS  program:  techmcal  reports,  a 
short  research  paper  to  be  presented  at  the  Third  IEEE  High  Assurance  Systems  En¬ 
gineering  Symposium  in  November,  PVS  libraries,  and  software  for  the  prototype  tools. 
The  technical  reports,  PVS  libraries  and  software  are  available  from  the  CSS  Web  Page 
(http  ://www.  securecomputing  .  com/css/).  The  libraries  are  in  the  form  of  PVS  dump 
files.  The  software  consists  of  Emacs  LISP  code  implementing  the  Specification  Browser  tool 
and  PVS  strategies  implementing  the  Analyst’s  Assistant  tool.  The  libraries  and  software  are 
described  in  the  corresponding  technical  reports.  This  section  presents  brief  descriptions  of  all 
technical  reptorts  written  for  the  program.  It  is  divided  into  sections  for  contract  dehverables 
(CDRLs)  and  a  short  research  paper. 


2.3.1  CDRL  Document  Summary 

This  section  describes  all  technical  reports  provided  as  contract  deliverables  (CDRLs).  The 
missing  CDRLs  in  this  hst  are  for  the  program  management  documents. 

Top-Level  Specification  (TLS),  CDRL  A004  [15] 

In  this  report  we  give  a  high  level  description  of  a  network-transparent,  distributed 
interprocess  commxinication  manager.  This  report  provides  a  baseline  specification  to  be 
used  in  other  CSS  tasks,  and  serves  as  an  example  starting  point  for  the  CSS  design 
methodology. 

Security  Policy  Composability  Results  (SPCR),  CDRL  AOOS  [21] 

We  describe  tools  and  a  methodology  for  analyzing  a  noninterference  property  called 
restrictiveness  in  the  CSS  composition  and  refinement  framework.  These  tools  take  the 
form  of  extensions  to  the  composition  and  refinement  framework  [14]  that  are  suited  for 
performing  security  analyses  of  systems  at  the  component  level. 

Refined  Design  Report  (RDR),  CDRL  A006  [14] 

This  report  serves  several  purposes  relating  to  the  use  of  our  composition  and  refinement 
framework.  The  biilk  of  the  report  exhibits  a  working  example  of  refinement;  the  top  level 
specification  of  a  network  server  (described  in  the  TLS  [15])  is  here  refined  into  a  detailed 
description  of  network  protocols  using  the  x-Kemel  methodology  [5].  The  document  also 
discusses  the  PVS  theories  comprising  the  framework  and  relates  lessons  learned  while 
designing,  implementing,  and  testing  the  framework. 

Tools  Report,  CDRL  A007  [22] 

This  report  contains  a  description  of  the  requirements,  design  and  code  for  prototype 
tools  developed  on  the  program.  Two  types  of  tools — a  browser  for  viewing  and  editing 
specifications,  and  PVS  strategies  to  help  in  the  formal  analysis  of  specifications — are 
covered. 

Modified  Top-Level  Specification  (MTLS),  CDRL  A008  [20] 

This  report  presents  a  modified  version  of  the  Top-Level  Specification  (TLS)  that  includes 
fault  tolerance  properties. 

Fault  Tolerance  Analysis  (FTAR),  CDRL  A009  [18] 
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This  report  presents  the  results  of  a  proof-of-(X)ncept  effort  to  reason  about  fault  tolerance 
properties  using  the  refinement  fii'amework.  An  architecture  for  fault  tolerance  is  specified 
and  analyzed. 

Final  Report,  CDRL  AGIO  [19] 

This  report  is  the  report  for  the  CSS  program  and  provides  an  overview  of  all  of  the 
technical  efforts  on  the  program.  It  describes  significant  accomplishments  and  obstacles 
encountered  during  these  efforts  and  lessons  learned  while  carrying  out  the  program. 
Finally,  it  provides  suggestions  for  future  efforts  which  build  ujxin  the  successes  of  the 
program  or  address  deficiencies. 

2.3.2  Research  Paper 

Using  Composition  to  Design  Secure,  Fault-Tolerant  Systems 
This  paper  summarizes  the  program’s  approach  and  results. 

2.4  Dependent  Programs 

Two  other  research  programs  at  SCC  have  benefited  finm  the  CSS  program. 

■  Assurance  in  the  Fluke  Microkernel  (AFM)  (June  1997  —  present) 

The  CSS  Framework  is  currently  being  used  in  two  ways  on  the  AFM  program  [17, 16].  A 
simplified  process  manager  and  file  server  are  being  specified  and  analyzed  with  the  goal 
of  further  demonstrating  and  exploring  the  use  of  the  framework.  At  least  two  levels  of 
abstraction  will  be  used:  an  abstract  requirements  level  and  a  more  detailed  ‘Implemen¬ 
tation  level.”  The  desired  properties  of  secure  process  creation  will  be  demonstrated  at  the 
requirements  level.  Lower  levels  will  be  shown  to  be  refinements  of  this  level,  therefore 
inheriting  the  desired  properties.  The  AFM  program  is  also  using  the  CSS  Framework 
to  perform  a  general  analysis  of  issues  involved  in  Tnaintaining  consistency  between  an 
object  manager  that  enforces  a  security  policy  and  a  security  server  that  supplies  security 
decisions  based  on  that  policy,  paying  si>ecial  attention  to  the  case  where  the  policy  can 
change  »nd  the  object  manager  caches  policy  decisions. 

■  Hypervisors  for  Security  ^nd  Robustness  (October  1996  —  March  1998) 

This  program  used  the  CSS  composition  and  refinement  framework  to  support  the  speci¬ 
fication  and  analysis  of  the  comi)Osition  of  a  kernel  with  security  hypervisors  that  monitor 
kernel  requests  to  provide  security  [23,  24]. 
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Section 


3 


CSS  Framework 


3.1  Goals 

The  primary  goal  of  this  portion  of  the  program  was  to  develop  a  formal  firamework  for  rea¬ 
soning  about  composite  systems  and  performing  formal  design  refinement.  This  provided  an 
underlying  framework  that  served  as  a  basis  for  the  remainder  of  the  work  on  the  program. 
Specific  goals  in  developing  the  framework  were  to  make  it  small,  easy  to  use  and  not  too  hard 
to  verify  while  still  providing  the  essential  reasoning  power. 

Composition  is  a  technique  for  specifying  a  laige  system  by  combining  the  specifications  of 
smaller,  simpler  pieces — the  system  components.  This  technique  provides  advantages  that 
are  similar  to  those  obtained  from  modiilar  software  design  The  smaller,  simpler  pieces  are 
typically  easier  to  write  and  maintain  This  technique  also  allows  for  reuse  of  specifications  for 
individual  components.  Just  as  a  well-designed  software  module  can  be  reused  in  a  variety  of 
new  contexts,  a  component  specification  can  be  combined  with  other  component  specifications 
in  novel  ways  to  obtain  new  ss^stem  specifications.  However,  the  benefits  do  not  stop  there. 
We  typically  wish  to  analyze  a  63^stem  specification  to  show  that  it  satisfies  certain  desired 
properties.  Composition  allows  us  to  decompose  this  analysis  into  the  analysis  of  the  compo¬ 
nents.  Rather  than  analyzing  the  entire  composite  S3^stem,  we  focus  on  a  single  component  at 
a  time,  showing  that  it  satisfies  some  more  localized  property.  We  then  show  that  the  localized 
properties  of  the  components  together  imply  that  the  global  desired  property  is  satisfied  by  the 
system  as  a  whole.  Since  the  local  analyses  depend  upon  only  a  single  component,  they  are 
not  only  simpler  but  also  reusable.  They  need  not  be  redone  when  the  component  is  used  in 
a  new  context.  In  addition  to  the  composition  of  pure  analyses  described  above,  we  can  also 
compose  conditional  analyses.  In  this  case,  we  show  that  a  component  satisfies  a  localized 
proi)erty  under  given  assumptions  about  the  environment.  When  we  compose  this  component 
with  others  we  show  that  the  other  components  justify  the  environment  assumptions.  One  can 
then  conclude  that  the  system  as  a  whole  satisfies  the  localized  property. 

Refinement  supports  reasoning  about  a  system  si)ecified  at  multiple  levels  of  abstractioiL  Re¬ 
finement  analysis  makes  it  possible  to  show  that  properties  demonstrated  for  an  abstract 
specification  are  preserved  in  a  less  abstract  refinement  of  that  si)ecification  that  reflects  a 
more  detailed  design.  It  is  usually  easier  to  prove  desired  system  properties  for  an  abstract 
specification  than  for  a  more  detailed  one.  On  the  other  hand,  it  is  easier  to  relate  a  detailed 
specification  to  its  implementation  since  it  includes  more  design  details.  The  goal,  of  course, 
is  to  know  that  the  implementation  satisfies  the  desired  properties.  Refinement  analysis  al¬ 
lows  us  to  conclude  this  by  proving  that  an  abstract  specification  satisfies  the  proi>erties,  then 
arguing  that  a  refined  specification  is  consistent  with  the  implemented  system  and  finally,  com¬ 
paring  the  two  specifications  to  show  that  the  refined  one  is  consistent  with  the  abstract  one. 
Thus,  we  only  need  analyze  the  property  at  the  abstract  level  where  this  anal3^s  is  easiest.  As 
with  composition,  refinement  can  be  pure  (no  assumptions  about  the  environment  are  needed) 
or  conditional  (the  implementation  argument  depends  on  assumptions  about  the  environment 
that  are  later  justified  by  other  components). 

Composition  can  be  thought  of  as  bottom-up  analysis;  properties  shown  to  hold  for  components 
are  true  of  the  composite  system.  Refinement  is  top-down  analysis;  properties  demonstrated 


5 


at  the  abstract  level  are  shown  to  be  true  of  more  detailed  levels  as  well. 

In  this  section  we  describe  the  CSS  Framework,  a  mathematical  framework  that  supports  the 
following: 

■  specifying  system  components  (Section  3.2.1), 

■  composing  components  (Section  3.2.2),  and 

■  performing  both  composition  and  refinement  reasoning  (Section  3.3.1). 

Comparisons  to  prior  work  are  included  in  Section  3.3.2.  The  framework  is  formalized  in  the 
PVS  si)ecification  language  [9],  and  all  results  have  been  proven  in  PVS.^ 

3.2  Approach 

3.2.1  Component  Definitions 

We  begin  by  outlining  the  information  that  comprises  a  compKinent  specdfi-cation  in  the  CSS 
framework.  Fach  component  specification  c  is  a  record  defining  the  actions  that  the  component 
is  willing  to  perform  »nd  placing  constraints  on  the  actions  its  environment  is  able  to  perform. 
For  each  component,  the  set  cags{c)  (short  for  TOmponent  ^ente)  denotes  a  set  of  agents  that 
mediate  actions  of  that  comj>onent.  The  set  ^zior(c)  (guarantee)  denotes  the  transitions  that 
the  component  can  perform.  A  transition  is  modeled  by  a  triple  (si ,  S2, «)  indicating  a  change 
of  state  from  to  62  mediated  by  agent  a.  Since  guar(c)  contains  transitions  performed  by  c, 
the  agent  of  each  guar  transition  must  be  in  oa^s(c). 

The  set  of  transitions  hidd{c)  (hidden)  denotes  the  set  of  external  (environment)  transitions 
allowed  by  the  component.  The  agent  in  a  hidd  transition  must  not  be  in  cags{c).  The  name 
hidd  is  deceptive.  It  suggests  data  or  transitions  that  are  private  and  cannot  be  observed  by 
other  components.  However,  hidd  really  denotes  a  set  of  transitions  allowed  in  the  environment. 
Visibility  plays  no  essential  role.  The  term  hidd  dates  from  early  versions  of  the  framework 
find  has  been  kept  primarily  for  historical  reasons  and  because  of  the  inertia  in  a  large  formal 
system. 

Examples  of  constraints  that  hidd  might  place  on  the  environment  include 

■  No  environment  agent  may  alter  the  internal  variables  of  c. 

■  Only  agent  a  may  alter  the  interface  that  c  presents  to  a. 

These  constraints  are  included  in  the  component  si>ecification  for  c  because  they  are  critical  for 
the  correct  operation  of  c.  The  specification  of  hidd  makes  composition  possible.  Section  3.2.2 
below  descries  how  hidd  is  applied  during  compositiorL 

For  convenience,  we  define  steps{c)  =  giiar{c)  U  hidd{c).  The  set  of  initial  states  allowed 
by  c  is  denoted  by  Fedr^ss  requirements  are  represented  by  two  fields,  wfar{c)  and 

s/ar(c),  corresponding  to  weak  and  spx)ng  fairness  conditions.  Fkimess  requirements  provide 
a  way  to  abstractly  specify  system  liveness  and  scheduling  properties.  Each  fairness  conihtion 
is  represented  by  a  set  of  transitions;  each  of  wfari^c)  and  sfari^c)  contain  a  set  of  fairness 

be  available  as  a  PVS  dump  file  on  the  CSS  Web  Page 
http  ://www .  secarecomputing  .  com/css/.  The  fi-ameworkie  described  in  detail  toward  the  end  of  the  CSS  Refined 
Design  Report  [14]. 
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conditions  (i.e.,  a  set  of  sets  of  transitions).  An  execution  histoiy  (i.e.,  trace)  i  for  the  system 
satisfies  a  weak  fairness  condition  F  €  wfar{c)  if  an  infinite  number  of  F-transitions  occur  in  i 
or  there  are  an  infinite  number  of  states  in  f  in  which  F-transitions  are  not  enabled  (i.e.,  there 
is  no  transition  in  F  that  starts  in  the  given  state).  Similarly,  an  execution  history  t  satisfies  a 
strong  fairness  condition  F  £  sfar{c)  if  an  infinite  number  of  F-transitions  occur  in  <  or  there 
is  some  point  in  i  after  which  F-transitions  are  never  enabled.^ 

These  six  fields  define  the  set  (mprop)  of  execution  histories  allowed  by  the  component: 

mprop{c)  =:  init{c)  n  {Dsteps{c))  n/atr.j?ncp(c), 

where  fair^rop[c)  denotes  the  histories  that  satisfy  all  the  weak  anrl  strong  fairness  conditions 
of  c,  and  □  is  the  temporal  operator  “always.”  This  formula  denotes  the  set  of  all  execution 
histories  that  start  in  a  state  in  init{c)y  that  contain  only  transitions  in  steps{c)  and  that  satisfy 
fair^rop[c).  This  set  of  histories  is  c^ed  the  property  of  c. 

The  two  remaining  fields  of  a  component  definition  are  view  and  rely.  The  former  describes 
the  portion  of  the  state  that  is  “visible”  to  the  component.  This  does  not  directly  enter  into 
the  property  definition  and  is  used  only  to  validate  that  the  other  fields  of  the  component  are 
defined  solely  in  terms  of  a  specific  portion  of  the  system  state  information  The  rely  field  is 
used  only  for  conditional  analysis  of  components.  This  is  discussed  in  Section  3.3.1. 

3.2.2  Composition 

The  basic  idea  of  composition  is 

■  the  composed  components  start  in  a  common  state  that  is  acceptable  to  all  of  them, 

■  the  components  take  turns  performing  transitions  that  are  allowed  by  all  the  components^ , 
and 

■  the  fairness  conditions  of  all  the  components  are  satisfied. 

We  define  the  expression  compose{S)  to  denote  the  composition  of  the  components  in  the  set  5. 
A  composite  system  is  itself  a  component  Let  d  =  compose{S).  Then 


init{d) 

=  fl  init{c) 

ees 

wfar{d) 

=  U  wfar{c) 

ces 

sfaT{d) 

=  U 

c€S 

cags{d) 

=  U 

c€S 

We  want  steps{d)  =  flees  ^  allows  only  steps  that  are  allowed  by  all  components). 

Using  cags{d)y  we  breai  this  intersection  into  the  desired  guar  and  hidd  for  d  as  follows.  We 
take 

hidd{d)  =  Pi  hidd{c). 
c€5 

^See  [14]  for  more  mformation  on  wfar  and  sfar  and  [6]  for  a  general  diecueeion  of  apeciiying  and  reasoning  about 
fairness  properties. 

^  We  consider  only  interleaving  representations  of  concurrency. 
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This  set  indudes  exactly  tiie  transitions  in  steps{d)  that  do  not  have  an  agent  in  c(igs{d).  We 
take 

giiar{d)  =  steps{d)  —  hidd{d), 

(i.e.,  the  set  of  all  transitions  in  steps{d)  having  an  agent  in  ca^s(d)).  Equivalently,  giiar{d) 
is  the  set  of  all  transitions  that  are  in  gaar{c)  for  some  c  G  5  and  in  steps{c)  for  all  c  G  S 
(i.e.,  those  transitions  that  can  be  performed  by  at  least  one  comix)nent  and  are  allowed  by  all 
components).  Note  that  we  allow  components  to  have  overlapping  cogs.  However,  if  for  every 
pair  of  com|X)nent6  in  S  the  cogs  sets  are  disjoint,  thenguar(c/)  is  the  set  of  all  transitions  that 
are  in guar[ci)  for  some  ci  G  5  and  in  hidd{c2)  for  all  C2  G  5,  C2  ^  ci .  This  means  that  the  hidd 
of  each  component  is  automatically  applied  to  the  guar  of  each  of  its  peer  compK)nents  during 
the  composition  of  the  components. 

This  automatic  application  of  the  hidd  values  is  important  from  a  standpoint  of  reuse  of 
specifications.  It  removes  the  need  to  modify  the  si>ecification  of  a  component  whenever  it 
is  to  be  composed  with  a  new  component.  It  also  allows  the  definition  of  a  component  to  focus 
entirely  on  its  own  state.  This  approach  does  however  give  hidd  great  power.  There  is  no  way 
in  this  framework  for  the  hidd  of  a  component  to  be  violated  by  one  of  its  pyeers  in  a  composite 
system.  This  is  why  we  stress  that  the  hidd  is  to  be  considered  part  of  the  specification  and 
any  valid  implementation  of  the  component  must  obey  the  requirements  expressed  in  hidd.  It 
is  every  bit  as  important  as  the  guar  in  achieving  a  faithful  implementation  of  the  component. 
In  analyzing  an  implementation  for  faithfulness  to  the  hidd,  it  may  be  necessary  to  consider 
other  pieces  of  software.  For  example,  the  hidd  of  a  component  might  say  that  certain  local 
variables  are  not  altered  during  environment  transitions.  An  implementation  might  achieve 
this  by  placing  these  variables  in  a  particular  region  of  memoiy  a^  relying  on  the  kernel  to 

■  protect  this  memory  from  other  processes  (i.e.,  to  maintain  address-space  separation), 
and 

■  not  alter  alter  the  memoiy  itself. 

Of  course,  the  component  itself  must  not  do  anything  that  would  subvert  the  hidd  such  as 
asking  the  kernel  to  share  the  private  region  with  other  processes. 

3.3  Accomplishments 

3.3.1  Composition  and  Refinement  Reasoning 

In  this  section  we  describe  several  theorems  for  reasoning  about  components  and  their  compo¬ 
sitions  and  refinements.  In  addition  to  these  spedfic  theorems,  the  framework  provides  a  wide 
variety  of  theorems  for  reasoning  about  general  system  properties  including  fairness  prope^ 
ties.  These  theorems  can  make  analysis  of  component  properties  easier.  They  can  even  make  it 
easier  to  perform  general  requirements  analyses  independent  of  any  component  specifications 
since  they  incorporate  the  mathematical  inductions  that  are  often  necessary  in  such  an^yses. 
For  example,  an  analyst  can  apply  a  single  theorem  to  reduce  the  proof  of  a  state  invariant  to 
a  proof  that  the  initial  state  satisfies  the  invariant  and  every  allowed  transition  maintains  the 
invariant. 

Since  the  result  of  composition  is  a  component,  any  place  we  refer  to  a  component  a  composition 
of  components  can  be  substituted. 

Once  a  component  is  specified,  one  typically  wants  to  prove  that  it  satisfies  certain  desired 
properties.  As  noted  above,  a  property  is  a  set  of  execution  histories.  A  component  c  is  said  to 


satisfy  a  property  P  if  mprop{c)  C  P.  The  following  theorem  clarifies  the  relationship  between 
compose  and  mprop.^ 

Theorem  1  (mprop  Intersection)  For  any  set  S  of  components, 

mprop(compose{S))  =  P|  mprop{c) 
ees 


It  is  a  trivial  consequence  of  this  theorem  that  if  c  satisfies  P,  then  so  does  every  composite 
system  containing  c  as  a  component.  This  supports  revise  of  analysis  and  the  decomposition  of 
a  satisfaction  proof  into  smaller,  componentrlocal  satisfaction  proofs. 

Frequently,  a  software  component  is  designed  so  that  it  satisfies  some  desired  property  as 
long  as  certain  assumptions  hold  true  for  its  environment  (e.g.,  the  processes  with  which  it 
communicates  follow  an  agreed  upon  protocol).  In  this  case,  we  say  the  component  conditionally 
satisfies  the  property.  To  show  that  it  satisfies  the  property  unconditionally,  we  must  show  that 
the  environment  justifies  the  assumptions.  In  the  CSS  Framework,  the  necessary  assumptions 
are  stored  with  the  component  in  the  rely  field  which  contains  a  set  of  environment  transitions. 
Unlike  hidd,  this  is  not  a  constraint  upon  an  implementation  of  the  component.  It  is  merely 
an  assumption  that  supports  conditional  satisfaction  analysis.  A  component  c  conditionally 
satisfies  property  P  if  P  contains  every  execution  history  in  mprop(c)  such  that  eveiy  transition 
is  either  in  rely{  c)  or  has  an  agent  in  cags{c).  The  following  theorem  makes  it  possible  to  convert 
a  conditional  satisfaction  result  for  some  component  to  an  unconditional  one  by  composing  the 
component  with  an  environment  that  justifies  the  assumptions;^ 

Theorem  2  (Composite  Satisfies)  For  every  set  of  components  5,  component  c  £  S  and 
property  P,  if 

1.  c  conditionally  satisfies  P,  and 

2.  every  transition  r  e  steps{compose{S))  is  either  in  rely{c)  or  has  an  agent  in  cags{c), 
then  composers)  satisfies  P  (unconditionally). 

Note  that  the  first  hypothesis  depends  only  upon  c  and  P.  Therefore,  its  analysis  can  be  reused 
when  c  is  composed  into  a  new  environment.  The  second  hypothesis  is  sensitive  to  the  removal 
or  modification  of  components  in  S,  but  not  to  their  addition.  It  is  thus  reusable  in  certain 
circumstances.  Also,  this  hypothesis  does  not  require  an  analyst  to  consider  all  components  in 
S.  Often,  one  or  two  components  in  S  supply  all  the  restrictions  on  r  necessary  to  satisfy  the 
hypothesis. 

There  is  an  alternative  to  conditional  satisfaction  analysis  that  is  also  supported  by  the  firame- 
work.  In  this  approach,  one  proves  that  a  component  satisfies  a  conditional  property  of  the 
form  P  Q  where  P  and  Q  are  both  properties.  One  must  show  that  every  execution  history 
allowed  by  the  component  (ignoring  any  assumptions  added  by  rely)  either  is  not  in  P  or  is 
in  C?.  If  the  goal  is  to  show  that  the  entire  system  satisfies  Q,  then  the  component  must  be 
composed  with  one  or  more  other  components  that  restrict  the  allowed  execution  histories  to 
those  in  P.  This  approach  is  actually  stronger  than  conditional  satisfaction  p  can  contain 
initial  state  restrictions  and  fairness  conditions  in  addition  to  transition  restrictions  as  can  be 
specified  in  rely. 

The  fiamework  also  supports  refinement  analysis.  A  component  c  is  a  refinement  of  (or  imple¬ 
ments)  another  component  d  if  mprop{c)  C  mprop{d).  This  is  a  useful  concept  ginr«P  property 

^  The  name  of  thie  theorem  in  the  PV^S  framework  is  mprop  jsonj^hm , 

^Thifi  ifi  theorem  compose  satisfies  in  the  PVS. 
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satisfaction  is  preserved  under  refinement.  Thus  properties  can  be  proven  at  an 
of  specification  and  a  refinement  analysis  can  then  be  performed  to  show  the  propertes  remam 
true  for  a  lower  level  specification.  Since  mprop{c)  and  mprop{d)  are  typic^y  infimte  sets  ol 
execution  histories,  which  are  themselves  infinite  sequences,  an  arbitraiy  refinement 
be  difficult.  The  following  theorem  reduces  the  proof  to  sufficient  conditions  that  are  much 


easier: 


Theorem  3  {mprop  Implementation)  For  any  two  components  c  and  d,  c  implements  d  if 

1.  init{c)  C  init{d) 

2.  steps{c)  C  steps{d) 

3.  mprop{c)  C  fair4)rop{d) 

Note  that  only  the  third  hypothesis  requires  reasoning  about  infinite  se^ences.  The^t 
two  hypotheses  deal  with  states  and  transitions.  Numerous  franiework  ffieorems  ^egar^ 
faimesrproperties  support  the  proof  of  the  third  hypothesis,  but  there  is  insuffiaent  space  to 

describe  these  here,  (See  [14].) 

When  c  and  d  are  both  composites,  the  proof  that  c  implements  d  can 

collection  of  smaller  proofs  showing  that  for  each  component  e  of  composite  d,  there  is  some 
set  5e  of  the  components  comprising  c  such  that  compose{St)  implements  e.  P^  ® 

usually  be  easier  than  the  large  one.  Furthermore,  each  ^bprrof  that 
e  is  likely  to  be  reusable  in  another  refinement  a^ysis  where  e  is 

level  components  5.  but  is  composed  with  a  different  set  of  components.  The  CSS  Framework 
contains  Lo  theorems  supporting  such  decompositions.  s^po^ 

pure  decompositions  in  which  the  subproof  for  each  e  is  entirely  independent  of  the  components 
not  in  St .  The  analyst  only  need  perform  each  of  the  subproofs. 

The  second  theorem,  decomp  Jhmjeduced,  supports  impure  decompwirions  where  a^^®^ 
of  the  subproofs  requires  assumptions  about  components  outside  the  subpro^  An  imp 
?e^m^^Sis  s^^es  necessary  if  the  granularity  of  transitions  changes  from  one  s^a- 
ficatiorievel  to  the  next.  As  with  conditional  satisfaction,  we  use  reZy  to  ^re  the  ^sumptions 
aSut  ffie  offier  remponente.  Assume  the  proof  that  c  implements  d  is  u^ly 
ffiton  hiproofs  tharc  implements  d.,  i  =  1.  ■  •  • ,  n.  The  following  must  be  demonstrated  for 

each  subproof  i. 

1.  The  refinement  is  vahd  assuming  reZy(c.)  is  never  violated  (we  call  this  conditional  im¬ 
plementation), 

2.  hidd{ci)Chidd{di),fiJDA 

3  every  transition  r  £  ,teps{o»npose({<i„  . ...  A.)))  is  either  in  n!ly(c,)  or  hM  “ 

So.)  (since  the  A  a«  more  abstreot  than  the  c,  this  will  typically  be  easier  than 
justLfyiiig  the  assumptions  in  terms  of  the  Ci), 

The  first  two  hypotheses  depend  only  upon  the  components  involved  in  ^bproof  »  a^  are 
therefore  reusal^  The  third  hypothesis  can  be  invalidated  by  the  removal  or  modifica^n  of 
SSSrnSTmposed  into  A  bTnot  by  the  addition  rf  new  cm^nents.  It  m  ^s 
reusS)le.  As  with  conditional  satisfaction,  the  an^yst  need  not  consider  all  the  d.  in  this 
hypothesis,  only  those  di  that  provide  the  necessary  information. 

6  This  IB  theorem  mprop SmplJhm  in  the  FVS. 
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3.3.2  Related  Work 


The  CSS  Framework  is  descended  from  an  earlier  version  developed  under  the  Distributed 
Trusted  Operating  Systems  (DTOS)  program  [12,  4].  The  DTOS  framework  de^t  with  compo¬ 
sition  only  wTifl  had  no  support  for  refinement  reasoning.  It  also  had  a  more  restrictive  defimtion 
of  a  components  property  in  which  rdy  was  used  in  place  of  hidd.  In  addition  to  asserting  that 
the  environment  assumptions  must  be  satisfied,  this  had  the  side  effect  of  intr^udng  an  0(n  ) 
proof  obhgation  (where  n  is  the  number  of  components)  in  the  DTOS  version  of  the  mptyp 
Intersection  theorem.  An  analyst  had  to  show  that  for  every  pair  of  components  (c,  d)  being 
composed,  guar{c)  n  hidd{d)  C  rely{d). 

The  DTOS  and  CSS  Frameworks  are  both  heavily  influenced  by  the  composition  work  of  Abadi 
mtiH  Lamport  [2]  which  is  couched  in  the  Temporal  Logic  of  Actions  (TLA)  [6]  and  by  ShankaFs 
composition  framework  [25].  TLA  specifications  (called  formulas)  are  similar  to  CSS  compo¬ 
nents  except  that 

■  they  do  not  have  explicit  agents, 

■  the  hidd  is  effectively  an  equivalence  relation  on  states,  and 

■  formulas  may  include  existential  quantifiers  to  hide  internal  state. 

We  added  agents  because  the  performer  of  an  action  is  important  in  certain  types  of  secu¬ 
rity  analysis,  one  of  our  primary  applications.  Having  agents  also  gives  us  the  flexibility  of 
distinguishing  between  environment  agents  in  our  hidd.  This  especially  makes  sense  when 
specifying  a  kernel  which  can  determine  the  identity  of  its  chents  and  keep  them  separate.  We 
explored  the  introduction  of  quantifiers  into  our  framework  but  decided  against  them.  They 
forced  a  great  deal  of  complexity  into  the  framework  in  terms  of  both  veriljdng  the  framework 
nnH  neing  it.  Having  qiiantifiers  would  have  introduced  an  0{n^)  proof  obligation  into  the 
mprop  Intersection  theorem  to  show  that  no  two  components  quantify  over  the  same  variable. 
Although  quantification  has  advantages  from  a  philosophical  standpoint,  its  practical  value  is 
more  suspect.  In  TLA  the  first  step  in  a  refinement  proof  is  typically  to  remove  the  quantifiers 
by  applying  a  refinement  mapping.  This  step  puts  the  proof  at  what  is  the  starting  point  for 
the  proof  in  our  framework.  If  no  refinement  mapping  can  be  found,  then,  although  the  re¬ 
finement  may  still  be  correct,  the  proof  is  likely  be  veiy  difficult.  So,  our  framework  makes  it 
easier  to  do  the  refinement  proofs  that  are  likely  to  be  feasible  at  the  expense  of  not  supporting 
refinement  proofs  that  are  likely  to  be  very  difficult.  Finally,  in  TLA,  composition  does  not 
automatically  apply  the  hidd  as  is  done  in  o\ir  framework.  Before  applying  the  TLA  equivalent 
of  the  mprop  Intersection  theorem  the  TLA  formulas  must  be  modified  “by  hand”.  Then  0{n^) 
proof  obligations  must  be  dispensed  to  show  that  the  hand  modifications  are  correct. 

3.4  Lessons 

The  most  important  lessons  from  the  development  of  the  CSS  Framework  are  reflected  in  its 
current  structure  and  in  technical  details  such  as  not  supporting  quantification  in  component 
si)ecifications. 

In  our  first  approach  to  the  framework  we  attempted  to  follow  the  Ahadi-Lamport  work  [2] 
rather  closely,  translating  their  concepts,  resiilts  and  proofs  into  FVS.  These  very  general 
results  would  then  be  applied  to  the  specific  style  of  component  specifications  used  in  our 
framework.  We  expected  this  approach  to  be  easier  than  trying  to  prove  similar  results  on 
our  own.  Through  our  efforts  to  achieve  this,  we  gained  a  much  better  understanding  of  the 
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Abadi-Lamport  results.  Eventually,  we  encountered  some  significant  difficulties  in  following 
this  approach,  but  the  understanding  we  gained  through  our  attempts  allowed  us  to  overcome 
these  difficulties  by  approaching  the  problem  from  a  different  direction.  The  difficulties  we 
encountered  stemmed  ^m 

■  the  central  role  of  invariance  under  stuttering  in  the  Abadi-Lamport  work  and  the  diffi¬ 
culty  of  dealing  with  this  concept  in  PVS, 

■  the  complexity  of  including  existential  quantification  in  the  framework,  and 

■  the  large  size  of  the  PVS  LISP  image. 

We  describe  each  of  these  difficulties  briefly  along  with  how  we  avoided  them  in  our  second 
approach  and  how  this  contributed  to  the  framework  goals  of  ease  of  use,  ease  of  verification 
and  sufficient  reasoning  power. 

One  of  the  assumptions  in  the  Abadi-Lamport  work  is  that  the  properties  considered  are 
invariant  under  stuttering.  This  means  that  if  a  behavior  <i  satisfies  some  property,  then 
so  does  every  behavior  <2  obtainable  from  by  adding  and  deleting  an  arbitrary  (possibly 
infinite)  number  of  stuttering  steps  (i.e.,  steps  in  which  no  state  change  occurs).  Although 
this  concept  is  fairly  intuitive,  it  is  somewhat  complicated  to  work  with  in  PVS.  A  good 
deal  of  mathematical  machinery  would  be  needed  in  the  framework  to  effectively  exploit  this 
assumption  in  the  framework  proofs.  Although  it  is  frequently  trivial  to  informally  compare 
two  infinite  sequences  to  see  whether  they  are  equivalent  up  to  stuttering,  doing  this  formally 
is  usually  a  good  deal  more  challenging,  especially  when  there  can  be  an  infinite  number  of 
places  where  stuttering  steps  have  been  added  or  removed.  However,  the  components  in  our 
framework  trivially  satisfy  invariance  under  stuttering  since  the  guar  and  hidd  are  required 
to  contain  all  stuttering  steps.  When  proving  theorems  about  arbitrary  composite  systems  it 
is  much  easier  to  work  with  the  guar  and  hidd  which  are  sets  of  transitions  than  to  apply  the 
more  abstract  notion  of  invariance  under  stuttering  which  deals  with  sets  of  infinite  sequences. 
Thus,  it  is  much  easier  to  take  components  (and  the  properties  they  define)  as  the  starting 
point  than  to  use  the  more  general  concept  of  properties  invariant  under  stuttering. 

While  attempting  to  follow  the  Abadi-Lamport  approach  we  did  search  for  a  simplification 
of  invariance  under  stuttering  that  woiild  be  easier  to  work  with  in  PVS.  For  example,  we 
attempted  to  use  a  definition  that  allowed  only  a  finite  number  of  stuttering  steps  to  be  added  or 
deleted.  However,  it  was  eventually  discovered  that  the  simpler  definition  is  insufficient  when 
dealing  with  existentially  quantified  properties  (to  be  discuss^  shortly)  since  the  quantification 
can  introduce  an  infinite  number  of  stuttering  steps.  Furthermore,  the  simplified  definitions 
were  still  not  very  easy  to  use  in  performing  the  verification  of  the  fr^amework  in  PVS.  In 
the  end,  we  abandoned  the  concept  of  invariance  under  stuttering  entirely,  relying  instead 
on  the  constraints  on  guar  and  hidd  in  the  framework.  This  decision  significantly  reduced 
the  size  and  complexity  of  the  framework,  and  this  contributed  to  the  goals  ease  of  use  and 
ease  of  framework  verification.  This  decision  had  little  if  any  effect  on  the  formal  power  of 
the  framework  since  the  intent  had  always  been  to  provide  a  componentibased  framework  to 
the  analysts.  Concepts  such  as  invariance  under  stuttering  were  included  only  to  support  the 
incorporation  of  the  Abadi-Lamport  proofs  as  general  results  of  which  the  componentibased 
theorems  would  be  corollaries. 

A  second  difficulty  encountered  in  our  original  approach  was  the  complexity  of  quantification 
in  specifications.  Quantification  supports  data  hiding  in  a  specification.  For  example,  it  allows 
one  to  specify  the  external  behavior  of  a  queue  (i.e.,  first  in,  first  out)  in  terms  of  a  convenient 
internal  representation  (e.g.,  a  sequence)  without  making  that  representation  externally  vis¬ 
ible.  By  not  including  quantification,  we  lose  the  ability  to  hide  the  internal  representatioiL 
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Of  course,  we  can  still  prove  within  the  framework  that  designs  using  two  different  represen¬ 
tations  are  equivalent  by  showing  how  the  representations  relate  to  each  other  Since  this  is 
essentially  what  happens  in  a  fiamework  that  supports  (quantification  when  a  refinement  map¬ 
ping  is  applied  to  quantified  specifications  during  analysis,  we  are  laaUy  jtist  recjuiring  that  the 
refinement  mapping  be  specified  when  the  specifications  are  placed  in  a  common  state  space 
for  analysis  rather  than  during  the  refinement  proof  itself.  This  may  well  be  a  feature  of  the 
framework  since  it  makes  the  refinement  mapping  (i.e.,  the  relationship  between  data  at  dif¬ 
ferent  specification  levels)  explicit  in  the  specifications  rather  than  hiding  it  in  the  refinement 
proof. 

It  was  also  realized  that  (quantification  would  significantly  increase  the  burden  on  users  of  the 
framework.  When  reasoning  about  composite  systems,  analysts  would  be  recjuired  to  show  that 
no  two  of  the  (X)mpK)nents  cjuantified  the  same  variable.  This  would  be  a  pairwise,  0{v?)  proof 
obligation.  As  with  invariance  under  stuttering,  the  decision  to  avoid  cpiantification  improved 
ease  of  use  and  verification,  and  it  reduced  the  size  of  the  framework.  Any  practical  reduction 
in  reasoning  power  is  Tninimal  since  it  is  usually  quite  difficult  to  perform  a  refinement  proof 
without  using  a  refinement  mapping.  Not  having  quantifiers  makes  it  impossible  to  do  (5ertain 
refinement  proofs  that  are  probably  impractical  to  perform  anyway.  At  the  same  time  it 
simplifies  the  proofs  that  are  practical. 

We  have  already  mentioned  that  the  decisions  to  focrus  on  components  rather  than  stuttering- 
invariant  properties  and  to  not  support  quantification  resulted  in  a  smaller  framework.  Aside 
from  concerns  of  ease  of  use  and  learning  curve,  this  had  some  veiy  practical  hardware  resource 
implications.  In  the  original  approach  we  noted  that  the  PVS  Lisp  image  was  getting  cjuite 
large  (e.g.,  50-60  Meg  for  just  the  framework).  We  realized  that  this  might  have  an  impact  on 
usability  of  the  framework  both  in  terms  of  the  hardware  demands  and  the  slower  speed  of 
PVS  when  the  image  gets  large.  We  were  able  to  significantly  reduce  the  image  size  in  going  to 
the  new  approach. 


3.5  Future  Work 

As  noted  in  Section  2.4,  the  Assurance  in  the  Fluke  Microkernel  program  is  currently  using 
the  CSS  framework  to  analyze  secure  process  creation  and  to  study  the  support  of  dynamic 
security  policies  in  a  distributed  environment. 

One  goal  of  the  CSS  program  was  to  demonstrate  that  composition  and  refinement  could  be 
used  for  a  variety  of  analyses  necessary  in  designing  systems,  especially  secure  systems.  It 
would  be  interesting  to  continue  this  demonstration  by  considering  other  types  of  analyses. 
For  example,  the  framework  could  be  used  to  study  analysis  of  real-time  properties  (see  [1]). 
This  not  only  has  broad  relevance  outside  security,  but  could  also  be  applied  to  the  analysis  of 
security  mechanism  such  as  real-time  audit.  Another  area  that  might  be  fruitful  is  the  analysis 
of  cryptographic  protocols,  especially  in  an  environment  where  the  protocol  is  implemented  by 
cooperating  (and  potentially  reusable)  components. 

Finally,  we  anticipate  that  a  variety  of  evolutionary  improvements  could  be  made  to  the  frame¬ 
work  itself.  It  could  be  fine-tuned  for  ease  of  use,  clarity  of  organizatioii,  quality  and  quantity 
of  documentation,  small  size,  etc. 
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Section  ^ 

Top  Level  Specification 


4.1  Goals 

The  Top-Level  Specification  (TLS)  effort  was  intended  to  serve  several  purposes,  the  foremost 
of  which  was  to  provide  a  starting  point  for  the  design  refinement  work  and  the  portion  of 
the  fault  tolerance  effort  in  which  an  existing  specification  (the  TLS)  is  modified  to  be  fault 
tolerant.  The  TLS  also  serves  as  an  example  of  how  to  specify  system  components  within  the 
CSS  Framework.  In  doing  this  we  took  the  position  (shared  by  earher  programs  such  as  DTOS 
[13])  that  a  component  Bi)ecification  Has  multiple  audiences  and  ought  to  be  readable  by  all 
of  them.  Thus,  it  should  contain  not  only  formal  notation  but  also  other  representations  of 
the  specification  such  as  English  text  wnH  processing  tables  (e.g.,  case  coverage  tables).  We 
furthermore  took  the  stance  that  a  formal  system  model  oxight  to  be  refined  in  parallel  with 
the  system  design  effort  and  that  throxxghout  this  refinement  process  it  is  important  to  keep 
the  formal  and  informal  descriptions  consistent. 


4.2  Approach 

The  chosen  functionality  to  be  specified  in  the  TLS  was  network-transparent,  distributed,  in¬ 
terprocess  communication  (IPC).  To  better  explore  the  refinement  of  a  design  finm  high-level 
requirements  to  a  detailed  design  we  included  two  levels  of  abstraction  within  the  TLS  itself 
(the  network  server  finm  the  second  level  is  further  refined  in  the  Refined  Design  Report).  The 
high  level  specification  consists  of  a  single  component  called  the  Box  Manager.  The  purpose  of 
thig  specification  is  to  describe  the  high-level  requirements  that  characteiize  IPC.  Commum- 
cation  is  controlled  by  capabihties  which  may  be  transmitted  in  messages.  The  Box  Manager 
Tnnintaing  these  Capabilities  and  manages  communication  boxes  that  serve  as  containers  for 
messages  in  transit.  The  refined  description  of  the  system  contains  components  for  kernels, 
network  servers,  and  a  network.  This  level  spells  out  the  details  of  a  particular  refinement  of 
the  Box  Manager  into  a  networked  system  with  multiple  nodes  (kernels),  network  servers  and 
a  network.  The  network  server  components  act  as  forwarding  agents  that  forward  node-local 
messages  to  network  servers  on  remote  nodes  for  dehveiy  to  the  appropriate  remote  client  and 
that  forward  messages  received  from  the  network  to  the  appropriate  local  client. 

To  address  the  goal  of  dose  correspondence  between  formal  in  informal  representations,  we 
organized  each  of  the  fom-  component  specifications  m  the  TLS  as  a  series  of  pairs  of  text  and 
formal  specification  (PVS)  elements.  This  makes  it  easier  to  visually  inspect  the  descriptions 
for  consistency.  We  also  induded  case-based  processing  tables.  (See  Section  8  for  information 
on  the  Specification  Browser  which  further  encourages  consistency  between  the  descriptions.) 

4.3  Accomplishments 

The  TLS  was  the  first  attempt  at  specifying  a  system  using  the  CSS  Framework  at  two  levels  of 
abstraction.  Having  two  levels  proved  to  be  very  useful.  First,  it  allows  the  critical  properties 
of  the  system  to  be  proved  at  a  more  abstract  level  where  the  proofs  will  typically  be  much 
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easier.  Meanwhile,  tiie  more  detailed  level  reflects  design  decisions  that  will  eventually  be 
followed  in  an  implemented  system.  This  level  has  a  stronger  resemblance  to  the  implemen¬ 
tation.  Combining  these  two  levels  and  showing  that  one  is  a  refinement  of  the  other  thus 
provides  important  guidance  and  assurance  to  the  design  eflTort.  No  significant  problems  were 
encountered  in  specifying  the  system  at  multiple  levels  although  we  did  not  have  sufficient 
time  to  perform  a  FVS  proof  that  the  kernel-network  level  is  a  refinement  of  the  Box  Manager. 

The  TLS  was  also  the  first  attempt  at  defining  and  composing  components  without  the  use  of 
state  and  agent  translators  which  were  used  heavily  in  applications  of  the  DTOS  Framework. 
The  framework  requires  that  all  components  to  be  composed  are  defined  on  a  common  “uni¬ 
versal”  state.  However,  when  defining  a  single  component  it  would  be  undesirable  to  have  to 
anticipate  the  state  information  of  all  the  other  components  with  which  the  current  compo¬ 
nent  might  someday  be  composed  so  that  that  state  information  can  be  included.  This  would 
make  it  much  harder  to  reuse  component  specifications  in  new  ways  and  would  thus  reduce 
one  of  the  mnin  benefits  of  the  fiamework.  So,  the  approach  in  the  DTOS  framework  was  to 
define  each  component  on  an  separate  state  type,  define  a  global  state  that  contains  all  the 
state  information,  and  then  define  translator  functions  that  map  each  local  state  to  the  global 
state.  It  was  noted  on  DTOS  that  this  was  fairly  clumsy.  In  addition  to  the  work  of  defining 
the  translators,  significant  portions  of  the  proofs  about  the  system  dealt  with  “applying”  the 
state  translations.  Since  the  translations  themselves  were  usually  trivial  project  functions, 
there  was  no  value  obtained  for  this  effort.  Furthermore,  it  was  realized  that  if  we  ever  used 
non-trivial  translators,  the  translators  themselves  could  obscure  the  true  nature  of  what  was 
being  proven  about  the  system. 

So  we  developed  an  alternative  approach  that  has  been  used  throughout  the  CSS  work — and  is 
also  being  used  in  the  Assurance  in  the  Fluke  Microkernel  program  (see  Section  2.4) — that  does 
not  require  translators.’^  This  approach  has  worked  quite  well.  As  in  the  translator  approach, 
for  each  type  of  component  we  define  a  local  state  type,  ignoring  possible  overlaps  with  other 
components.  Shared  data  types  and  global  “configuration”  information  are  defined  in  a  low 
level  PVS  theory  called  config  which  is  imported  by  aU  other  state  models.  The  local  state 
definitions  are  combined  in  the  theory  common^tate  with  a  separate  field  for  each  local  state. 
Each  component  is  defined  directly  on  the  common  state  but  all  of  its  accesses  are  to  its  local 
portion  of  that  state  via  the  appropriate  field  accessor  function.  Thus,  the  component  really 
only  depends  upon  its  local  state.  As  components  are  added  or  removed,  the  changes  to  global 
state  are  isolated  to  the  two  theories  config  and  common^tate.  Since  each  component  is  defined 
with  respect  to  one  field  of  the  common  state,  the  addition  or  removal  of  fields  has  no  effect  on 
the  other  components  nor  their  proofs.  This  provides  the  desired  reusability  of  specifications 
without  the  use  of  translators. 

In  the  favilt  tolerance  work  we  considered  using  the  Box  Manager  as  an  abstract  specification 
of  communication  between  the  fault  tolerance  components.  However,  the  faiilt  tolerance  com¬ 
munication  requires  firstiin  first-out  (FIFO)  communication  that  this  is  not  specified  in  the  Box 
Manager.  Thus,  the  specification  of  EPC  in  the  Box  Manager  may  be  too  general  for  some  po¬ 
tentially  profitable  uses.  FIFO  was  not  needed  for  the  critical  properties  that  were  anticipated 
when  writing  the  Box  Manager,  and  omitting  this  requirement  resulted  in  a  simpler  specifi¬ 
cation  This  is  likely  to  be  a  perpetual  question  in  writing  specifications:  what  requirements 
ought  to  be  specified  to  give  the  specification  broad  application  without  making  it  too  laige, 
complex  or  cluttered.® 

^  In  fact,  the  concept  of  translatorB  has  been  removed  entirely  from  the  framework. 

*On  the  Afisurance  in  the  Fluke  Microkernel  program  we  are  currently  exploring  an  approach  that  could  be  used 
to  alleviate  thifi  problem.  New  requiremente  can  often  be  added  by  composing  in  a  new  system  component  at  the 
requirements  level  that  further  constrains  the  system  to  obey  the  new  requirement.  Thus,  a  FIFO  component  could 
assert  that  the  communication  mediated  by  the  Box  Mansger  must  be  FIFO. 
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4.4  Lessons 

The  lessons  finm  this  task  relate  closely  to  the  achievements  described  in  the  previous  section: 

■  State  and  agent  translators  are  not  necessary 

■  Specifying  a  system  at  multiple  levels  of  abstraction  has  significant  advantages. 

■  It  is  not  always  easy  to  reuse  a  specification  because  the  needs  of  its  new  use  might  not 
match  those  of  its  earlier  use. 

The  first  lesson  is  important  for  the  usability  of  the  CSS  Framework.  Given  prior  exi>erience 
in  the  field  of  formal  methods,  the  second  and  third  lessons  hardly  seem  surprising. 

4.5  Future  Work 

One  thing  that  we  had  hoped  to  do  but  for  which  we  had  insufficient  time  was  to  perform  a  PVS 
proof  that  the  kernel-network  level  is  a  refinement  of  the  Box  Manager.  We  expected  to  learn 
some  things  about  refinement  arguments  and  about  high-level  specifications  by  doing  this.  In 
particular,  this  refinement  step  moves  fix)m  a  high  level  in  which  clients  can  directly  refer  to 
boxes  to  a  low  level  in  which  they  reference  them  indirectly  through  names  in  a  name  space  that 
the  kernel  Tnflint.flins  for  each  client.  This  is  likely  to  introduce  complexities  into  the  refinement 
mapping.  Furthermore,  we  expect  this  refinement  from  direct  to  indirect  references  to  be  a 
common  theme  in  refinement  aiguments  since  it  is  much  easier  to  analyze  critical  properties 
when  direct  references  are  used,  yet  the  underlying  implementation  will  frequently  provide 
only  for  indirect  references. 
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Section 


Design  Refinement 


5.1  Goals 

One  of  the  main  goals  of  the  CSS  Framework  is  to  support  the  refinement  of  an  abstract  design 
to  a  more  detailed  one.  The  goal  of  the  Design  Refinement  task  was  to  demonstrate  the  use  of 
refinement.  In  particular,  we  wished  to 

■  refine  the  network  server  specification  in  the  TLS  which  served  as  the  abstract  design, 

■  explore  any  issues  in  refining  a  design, 

■  provide  an  example  of  refiinement  analysis,  and 

■  test  the  refinement  portion  of  the  framework. 

6.2  Approach 

To  demonstrate  the  use  of  the  framework  for  refinement  reasoning,  we  refined  the  abstract 
design  for  a  network  server  from  the  TLS.  The  network  server  acts  as  the  interface  between  a 
kernel  «rid  a  network.  The  sole  function  of  the  network  server  is  to  act  as  a  “forwarding  agent” 
for  messages  being  passed  between  tasks  on  the  local  node  and  tasks  on  remote  nodes.  The 
operations  of  the  network  server  implement  two  high  level  actions:  receive  a  local  message  and 
forward  it  on  to  a  remote  network  server,  and  receive  a  message  finm  the  network  and  forward 
it  on  to  a  local  client. 

The  network  server  specification  does  give  a  fairly  detailed  description  of  the  processing  re¬ 
quired  to  carry  out  forwarding  operations.  However,  the  network  interface  is  left  extremely 
abstract — the  network  is  viewed  as  a  bag  of  messages,  and  message  transmission  is  specified 
as  addition  to  and  removal  finm  the  message  bag.  The  next  step  was  to  refine  this  abstract 
design  to  a  traditional  layered  protocol  stack  architecture.  We  refined  message  transmission 
to  the  level  of  IP  packets  and  frames  being  transmitted  via  an  Ethernet  medium.  We  adopted 
the  z-Kemel  architecture  [5]  as  a  model  for  our  protocols;  the  modularity  and  dean  interface 
definition  of  z-Kemel  protocols  work  well  with  the  CSS  fi-amework  and  provide  a  versatile 
specification  paradigm  for  defining  protocol  components.  In  particular, 

■  The  z-Kemel  separation  of  protocols  is  easy  to  specify  in  our  framework  and  reinforces 
the  design  objectives  of  composition  In  essence,  the  z-Kemel  protocol  architecture  is  a 
compositional  framework. 

■  The  flexibihty  of  the  z-Kemel  architecture  allows  maximal  benefits  finm  re-usable  anal¬ 
ysis.  By  enforcing  strict  modularity  on  its  protocols,  the  z-Kemel  allows  systems  to  be 
easily  reconfigured,  thus  providing  an  opportunity  for  re-usable  components. 

■  Uniformity  of  z-Kemel  communication  allows  re-usable  transition  specifications.  The 
transitions  that  define  the  open  and  demux  operations  in  the  z-Kemel  architecture  are 
generic — they  are  virtually  the  same  for  all  protocols. 
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Our  x-Kemel  stack  consists  of  CSS  components  implementing  the  following  seven  protocols: 

■  FWD  This  component  is  not  strictly  a  protocol  in  the  sense  defined  by  the  x-kemel 
architecture;  it  has  an  interface  with  the  lower  protocol — ^DNS — ^but  it  does  not  present 
the  standard  interface  for  communicating  with  higher  protocols  (it  communicates  with 
a  local  kernel  component.)  The  FWD  protocol  is  si)ecified  in  the  same  format  as  the 
lower  protocols  and  for  simplicity  we  include  it  in  our  stack  definition  The  FWD  protocol 
implements  the  forwarding  operations  of  the  network  server,  but  unlike  the  network 
server  component  in  the  TLS  it  relies  on  the  lower  protocols  for  transmission  of  messages 
across  the  network. 

■  DNS  This  protocol  specifies  a  simple  domain  name  server  for  maintaining  bindings  be¬ 
tween  local  host  names  and  IP  addresses.  Dur  specification  does  not  allow  dynamic 
bindings;  rather  we  use  a  static  look-up  table  for  address  translations. 

■  DSS  A  digital  signature  protocol  for  signing  messages.  The  signatures  are  not  visible  at 
the  user  level;  they  are  used  between  remote  stack  instances  to  ensure  message  authen¬ 
ticity.  We  do  not  specify  a  particular  signature  algorithm. 

■  DES  A  message  encryption  protocol  for  maintaining  message  confidentiality.  Again  we 
do  not  specify  a  particular  algorithm. 

■  TCP  A  protocol  for  manf^ging  communication  sessions,  modeled  on  the  standard  Trans¬ 
mission  Control  Protocol  as  described  in  the  Intemic  RFC  793.  We  do  not  implement  the 
fiill  functionality  defined  in  the  RFC  standard;  in  particular  we  speciali2e  the  protocol  to 
handle  non-interactive  one-way  transiwrt  of  IPC  messages. 

■  IP  A  protocol  for  implementing  best^effort  connectionless  packet  delivery,  modeled  on  the 
standard  described  in  the  Intemic  RFCs  791,  950,  919  and  922. 

■  ETH  This  protocol  represents  a  simple  Ethernet  driver.  It  maintains  bindings  between 
IP  addresses  aiid  physical  addresses;  we  do  not  model  the  acquisition  of  bindings  through 
the  ARP  protocol,  but  rather  specify  that  bindings  are  contained  in  a  static  look-up  table. 

5.3  Accomplishments 

One  accomplishment  of  this  task  was  the  demonstration  that  the  CSS  Framework  supports 
the  specification  of  an  x-Kemel  protocol  stack  very  well  and  that  the  x-Kemel  architecture  is 
especially  appropriate  for  a  component/based  specification  and  analysis  style.  The  dean  design 
of  thf*  x-Kemel  architecture  makes  a  oomponentrbased  specification  particularly  convenient. 
The  consistency  of  interface  between  the  protocol  components  makes  it  easy  to  reuse  pieces  of 
the  si>ecification  and  analysis. 

We  also  outlined  the  proof  that  the  stack  is  a  refinement  of  the  abstract  network  server.  The 
refinement  analysis  technique  is  very  valuable  for  analyzing  complex  pieces  of  software  such 
as  a  network  stack.  The  high-level  specification  of  the  network  server  abstracts  out  the  many 
details  that  are  needed  for  realistic  network  communication,  focusing  instead  on  the  high-level 
behavior  required  of  the  communication  mechanism.  This  makes  it  much  easier  to  prove  that 
the  overall  system  of  which  the  network  server  is  only  a  part  has  the  desired  properties.  This 
proof  would  be  much  more  diflficult  if  the  full  network  stack  were  induded  in  the  anal3rsis.  On 
the  other  hand,  the  abstract  network  server  must  eventually  be  implemented  and  this  means 
dealing  with  all  the  complex  low-level  issues  that  are  necessary  to  communicate  over  a  network. 
Refinement  analysis  allows  an  analyst  to  spedfy  the  low-level  details  (to  whatever  extent  is 
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deemed  necessary)  nnd  to  then  show  that  the  resulting  network  stack  is  a  refinement  of  the 
abstract  network  server.  This  increases  the  confidence  that  the  implemented  system  preserves 
those  characteristics  of  the  abstract  design  that  were  essential  in  proving  the  desned  high-level 
properties  of  the  system. 

5.4  Lessons 

One  interesting  realization  that  came  from  this  work  is  that  fairness  conditions  in  a  high-level 
specification  can  never  be  entirely  implemented  (i.e.,  without  specifying  fairness  conditions) 
at  lower  levels — there  must  be  some  fairness  condition  at  each  refinement  level.  Even  though 
a  specific  scheduling  algorithm  might  be  added  at  lower  levels  to  define  how  the  high-level 
actions  governed  by  fairness  conditions  are  scheduled,  it  will  still  be  necessary  to  include  a 
fairness  condition  requiring  that  the  scheduler  itself  be  treated  fairly. 

The  other  main  lesson  deals  with  the  care  required  in  writing  the  specifications  at  both  the 
high  and  low  levels  to  ensure  that  the  refinement  is  in  fact  valid.  At  the  high  level,  one  must 
fight  the  strong  tendency  to  overspecify  the  system.  There  are  several  advantages  that  might 
typically  be  obtained  by  keeping  the  abstract  specification  as  unconstrained  as  possible: 

■  It  will  have  greater  potential  for  reuse  since  there  will  be  more  ways  to  refine  it. 

■  It  will  be  easier  to  show  that  a  given  implementation  is  a  refinement  of  the  abstract 
specification  since  there  will  be  fewer  constraints  that  must  be  demonstrated  of  the  im¬ 
plementation. 

■  It  might  even  be  easier  to  prove  that  the  abstract  specification  satisfies  the  desired  critical 
properties  since  there  will  be  fewer  details  that  might  clutter  and  obscure  the  proof. 

At  the  low  level,  one  must  be  careful  not  to  make  tadt  assumptions  derived  from  the  high 
level.  For  example,  if  one  component  is  spht  into  many  we  must  be  sure  to  specify  the  allowed 
interactions  between  the  low-level  components  so  that  they  cannot  do  things  to  each  other  that 
the  high-level  component  cannot  do  to  itself  Otherwise,  the  refinement  alignment  will  likely 
Ml.® 

We  also  learned  that  specifying  a  component  in  the  “simplest"  way  can  sometimes  introduce 
subtle,  undesirable  constraints.*®  Consider  an  abstract  component  c  that  has  two  variables, 
i  for  input  and  o  for  output.  At  any  time  it  can  dedde  to  copy  t  to  o.  It  does  not  allow  any 
other  changes  to  o.  Now  assume  that  we  wish  to  refine  c  to  consist  of  a  series  of  network  stack 
components  with  a  network.  The  variable  i  corresponds  to  one  end  of  the  communication  and  the 
variable  o  to  the  other.  Each  intermediate  component  performs  copy  operations.  Unfortunately, 
this  is  not  a  valid  refinement.  At  the  high  level,  if  o  changes,  it  must  change  to  the  value  in  t. 
However,  at  the  low  level,  it  may  change  to  the  input  value  of  the  final  network  stack  component 
in  the  and  this  value  need  not  equal  the  input  value  for  the  first  network  stack  component 

in  the  chain  The  problem  is  that  the  specification  for  c,  although  simple,  is  too  constrained.  It 
asserts  that  c  can  deal  with  only  one  value  at  a  time.  This  prevents  refinement  to  a  low  level 
in  which  multiple  values  are  in  transit  We  can  make  c  less  constrained  by  allowing  it  to  keep 
additional  internal  state  to  hold  the  values  in  transit.  Depending  upon  the  properties  needed 
in  c,  this  state  could  be  a  queue,  a  set  or  a  bag  (i.e.,  a  “sef  that  can  contain  multiple  copies  of 
the  same  value).  The  low  level  discussed  above  is  a  refinement  of  this  regardless  of  wWch  of 
the  three  options  is  selected. 

®ThiB  was  also  obeerved  in  the  fault  tolerance  task. 

observation  also  arises  from  the  fault  tolerance  proof-of-concept  work  where  the  initial  specification  of  the 
fault-free  model  was  very  simple  but  too  constrained  to  allow  the  intended  refinement. 
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5.5  Future  Work 

We  had  insufficient  resources  on  the  program  to  complete  the  refinement  anal^^in  PVS. 
Since  the  process  of  doing  such  proofs  (and  in  particular,  machine  checked  p^fs)  fi^quentiy 
uncovers  errors  in  the  specifications  it  wotild  be  valtiable  to  perform  more  of  this  anal^is.  e 
expect  that  more  could  be  learned  about  the  kinds  of  errors  that  occur  in  refining  a  specification 
and  how  those  errors  might  be  avoided. 

In  Section  3.3.1  we  discussed  impure  decomposition  of  refinement  proofs  and  the  support 
provided  by  the  framework  for  these  decompositions.  However,  the  examples  considered  on 
this  program  all  ended  up  involving  pure  decompositions.  As  a  test  of  the  theorems  for  impure 
decomposition,  it  would  be  valuable  to  work  an  example  that  involves  impure  decomposition. 
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Section 


6 

Fault  Tolerance 


6.1  Goals 

The  purpose  of  this  task  is  to  demonstrate  the  use  of  compositioii  and  refinement  for  the  spec¬ 
ification  nnH  analysis  of  fault-tolerant  systems.  This  effort  included  not  only  specifying  new 
systems  but  also  modifying  existing  systems  to  be  fault  tolerant.  The  composition  framework 
lets  us  reason  effectively  about  a  system  as  a  set  of  components.  Eault-tolerant  systems  possess 
certain  characteristics  that  make  them  well-suited  for  analysis  within  a  composition  frame¬ 
work.  For  example,  potentially  faulty  components  are  replicated  to  achieve  faiilt  tolerance.  The 
composition  framework  lets  us  reason  about  one  replica  and  reuse  the  analysis  for  the  other 
rephcas.”  Fault  tolerant  systems  also  have  certain  unique  requirements,  such  as  the  need  to 
replicate  the  inputs  to  aU  replicas  and  to  vote  across  the  outputs  of  aU  replicas.  The  composition 
frnmework  let  iis  model  these  unique  requirements  as  separate  components,  which  keeps  the 
model  flexible.  This  task  also  demonstrated  how  to  modify  an  existing  specification  (the  TLS) 
to  make  it  fault  tolerant. 


6.2  Approach 

Before  describing  our  approach,  it  is  useful  to  understand  certain  facts  about  fault  tolerant 
systems.  A  system  is  fault-tolerant  it  behaves  like  a  faxilt  free  system  even  in  the  presence  of 
faiilts.  Our  focus  is  on  hardware  faxilt  tolerance,  i.e.,  the  ability  of  a  software  system  to  tolerate 
faults  that  originate  in  hardware.  Hardware  faxilt  tolerance  differs  significantiy  from  software 
fault  tolerance,  i.e.,  the  ability  of  a  software  system  to  tolerate  softxvare-induced  faults.  Butler 
[3]  argues  that  the  standard  method  for  achieving  hardware  fault  tolerance,  i.e.,  component 
replication,  is  not  effective  for  software  fault  tolerance,  because  the  conditions  that  cause 
software  faults  cannot  be  isolated  easily. 

Schneider  [11]  describes  two  classes  of  hardware-based  faults; 

1.  fail-stop:  a  faulty  component  transitions  to  a  state  where  other  components  can  detect  its 
failure,  and  then  stops,  and 

2.  Byzantine:  a  faulty  component  acts  arbitrarily  or  even  maliciously. 

A  t  faxilt>tolerant  system  exhibiting  Byzantine  failxires  must  have  at  least  2t  -|- 1  replicas  to 
ensxire  a  correct  vote,  while  the  same  system  exhibiting  fail-stop  failures  reqxiires  only  t  -f  1 
replicas.  According  to  Schneider  [11],  every  nonfaxilty  replica  shoxild  receive  every  request 
(Agreement),  and  every  nonfaxilty  replica  shoxild  process  the  requests  it  receives  in  the  same 
order  (Order).  Agreement  is  satisfied  when  the  client  transmits  the  same  request  to  all 
replicas.  ORDER  is  satisfied  when  all  nonfaxilty  replicas  obey  a  request  sequencing  protocol 
that  causes  them  to  process  recjuests  in  the  same  order. 

The  fault  tolerance  composition  study  is  divided  into  two  phases: 

^  ’  We  did  not  follow  that  approach  here,  becauae  our  replicas  were  very  simple. 
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1.  Proof-of-concept.  Study  the  specification  and  verification  of  fault  tolerance  properties 
from  a  composability  perspective. 

The  proof-of-concept  introduces  the  key  concepts  for  a  fault  tolerant  system:  the  replica¬ 
tion  of  the  potentially  faulty  component,  a  replicator  component  to  provide  inputs  to  all 
of  the  (potentially  faulty)  replicas,  and  a  voter  component  to  combine  the  outputs  of  the 
replicas. 

These  results  are  presented  in  The  Fault  Tolerance  Analysis  Report,  CDRL  A009  [18]. 

2.  TLS  modification.  Extend  the  Top-Level  Specification  (TLS)  CDRL  A(X)4  [15]  to  include 
fault  tolerance  properties. 

The  TLS  describes  four  components:  an  abstract  component  called  the  Box  Manager  and 
its  implementation  in  three  components,  the  kernel,  the  network  server  and  the  network. 
Our  focus  was  on  the  implementation  We  assumed  that  the  network  server  may  be  faulty, 
and  we  proposed  a  faulti tolerant  architecture  that  replicates  the  network  server  and  its 
associated  network. 

These  results  are  presented  in  The  Modified  Top  Level  Specification,  CDRL  A008  [20]. 
6.2.1  Proof-of-Concept  Approach 

In  the  proof-of- concept  phase,  we  proi)osed  a  simple  faxilt  tolerant  model  and  demonstrated  its 
validity  by  postulating  a  fault  free  model  and  proving  that  the  fault  tolerant  model  behaves 
like  the  fault  free  model.  The  fault  free  model  consists  of  a  single  state  machine  S  that  accepts 
requests  from  its  environment  and  generates  responses.  State  machine  S  supports  three 
transitions  (see  Figure  1): 

1.  If  a  new  request  arrives  over  the  recv  interface,  it  is  placed  on  the  queue  unproc  for 
unprocessed  messages. 

2.  If  unproc  is  not  empty,  remove  the  request  at  the  head  of  unproc,  process  it  via 

process-msg  :  message, proc^tate  (message, procMate), 

place  the  result  (the  response)  on  the  processed  message  queue  proc  and  update  the 
processing  state,  processjnsg  takes  a  processing  state  as  well  as  the  message  because 
the  state  may  influence  the  response.  In  addition  to  the  response,  it  returns  a  processing 
state  so  that  we  may  consider  state  machines  whose  response  depends  upon  the  history 
of  past  processing. 

3.  If  proc  is  not  empty,  the  head  response  is  removed  and  transmitted  over  the  send 
interface. 

The  two  queues,  unproc  and  proc,  make  possible  the  refinement  to  the  fault  tolerant  model 
which  can  have  multiple  messages  in  progress. 

There  are  few  constraints  on  5  or  its  environment.  Requests  issued  by  a  single  client  to  S  are 
processed  by  5  in  the  order  they  were  issued.  The  interaction  between  clients  is  invisible  in 
our  model  because  dients  are  part  of  the  environment. 

We  developed  an  abstract  representation  of  network  communication  using  a  shared  interface. 
When  component  A  wishes  to  send  a  message  m  to  component  B,  it  places  m  in  the  variable 
msg  that  it  shares  with  B  and  sets  the  done  flag  to  FALSE.  Component  B  recognizes  that  a 
new  message  has  arrived  when  it  detects  that  done  is  no  longer  true.  B  extracts  m  from  msg 
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Figure  1:  The  Fhult-Free  Model 

and  sets  done  to  TRUE.  The  shared  interfaces  are  configured  so  that  messages  are  transmitted 
in  one  direction  only.  If  B  needs  to  reply  to  >1,  it  uses  a  different  interface.  Each  component  has 
an  interface  for  outlx>;ind  messages,  called  send,  and  an  interface  for  inbound  messages,  called 
recv,  except  for  the  replicator,  which  has  three  outbound  interfaces,  and  the  voter,  which  has 
three  inbound  interfaces.  The  send  interface  of  a  component  is  equated  with  the  recv  interface 
of  the  component  to  which  it  sends  messages.  The  communication  model  satisfies  Schneidei^s 
assumption  that  communication  between  components  is  FIFO  and  nonfaiilty,  i.e.,  messages  are 
not  randomly  created,  mangled  or  lost.  Each  component  specification  must  constrain  how  the 
interface  is  modified.  Since  tbis  behavior  is  gimilar  fiiom  component  to  component,  we  defined 
helper  functions  to  simphiy  the  task. 

The  fault  tolerant  model  (see  Figure  2)  assumes  S  may  be  faulty.  It  replicates  5,  yielding  51, 
52  arid  53,  and  adds  a  replicator  R  and  voter  V.  We  introduced  a  third  component,  a  fault 
generator,  to  avoid  modifying  5  to  generate  faults.  We  associated  a  facilt  generator  (FI,  F2 
and  F3,  respectively)  with  each  replica  to  generate  any  faults  that  might  occur  in  the  replica. 
The  number  of  fault  generators  that  fWTi  be  in  fatilt  mode  is  limited  by  the  failure  class,  i.e., 
fail-stop  or  Byzantine.  Ifthe  failure  dass  is  fail-stop  a  fault  generator  in  fault  mode  discards  aU 
messages.  If  the  failure  class  is  Byzantine,  a  fault  generator  in  fault  mode  behaves  arbitrarily. 
If  a  sufficient  number  of  5  replicas  agree  on  their  output  and  if  this  output  matches  the  output 
of  the  single,  fault  free  5  for  all  given  request  sequences,  then  the  proposed  model  is  fault 
tolerant. 

The  relationship  between  the  fault  tolerant  model  and  the  fault  free  5  is  indicated  by  the 
dashed  box  in  Figure  2.  Note  that  while  R  accepts  messages  for  all  sending  clients,  there  may 
be  a  different  V  for  each  receiving  client 


Figure  2:  The  Fhult  Tolerant  Model 
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We  modeled  only  three  replicas,  because  three  is  the  smallest  number  of  replicas  that  make 
reasoning  about  Byzantine  behavior  interesting.  We  could  have  avoided  specifying  the  number 
of  replicas  since  the  number  of  replicas  needed  is  a  function  of  the  number  of  tolerated  faults:  to 
tolerated  faults,  <  +  1  replicas  are  required  in  the  fail-stop  case  and  2<  +  l  replicas  are  required  in 
the  Byzantine  case.  Modeling  a  specific  number  seemed  a  simpler  task  for  the  proof-of-concept, 
and  it  still  demonstrates  the  approach.  Our  model  explicitly  assumes  t  <  1  for  the  Byzantine 
case  and  it  allows  as  many  as  two  faults  for  the  fail-stop  case. 

Request  ordering  is  a  critical  issue  for  fault  tolerant  sj^stems.  Without  it,  voting  may  be 
impractical.  Request  ordering  is  also  crucial  for  the  consistency  of  the  internal  state  of  the 
nonfaulty  replicas.  Schneider  [11]  described  three  protocols  that  ensure  that  all  replicas  process 
the  same  sequence  of  requests.  Two  protocols  are  clock-based,  while  the  third  lets  replicas 
determine  the  proper  order  among  themselves.  In  general,  Schneidei^s  protocols  are  ^earliest 
first” .  However,  the  strategy  itselfdoes  not  matter,  oiy  that  all  replicas  adopt  the  some  strategy. 
The  fault  free  model  assumes  nothing  about  the  sequence  of  reqpiests  from  5*6  environment.  5 
processes  the  requests  in  whatever  order  they  arrive.  In  the  fault  tolerant  model,  we  had  to 
ensure  that  replicating  S  and  introducing  a  new  component  to  handle  request  dissemination 
did  not  affect  the  order  of  requests. 

Initially,  we  considered  implementing  one  or  more  of  Schneider^s  order  protocols;  however,  we 
discovered  that  each  protocol  introduces  significant  complications  for  our  analysis.  The  clock- 
based  protocols  require  that  each  client  attach  a  timestamp  to  each  request.  We  could  either 
require  this  behavior  of  the  client  or  introduce  another  component  to  perform  the  task  on  behalf 
of  the  client.  A  similar  component  would  be  required  at  each  replica  to  arrange  the  requests 
according  to  their  timestamps.  Schneidex^s  third  protocol  introduces  significant  inter-replica 
communication  and  requires  yet  another  component  (different  from  the  dock-based  protocols). 
We  realized  that  additional  constraints  would  be  needed  on  the  fault  free  model  in  order  to 
prove  that  the  fault  tolerant  model,  observing  a  particular  request  order  protocol,  implements 
the  fault  fiee  model.  For  example,  if  the  fault  tolerant  model  ordered  requests  by  timestamps, 
we  would  have  to  constrain  5  in  the  fault  fiee  model  to  also  order  requests  by  timestamps.  As 
a  result,  there  would  exist  several  fault  fiee/fault  tolerant  model  pairs,  each  flavored  by  the 
chosen  request  order  protocol.  To  simplify  the  problem,  we  avoided  implementing  any  of  the 
protocols. 

Instead  we  adopted  a  much  simpler  approach.  The  requirement  for  a  request  ordering  protocol 
is  motivated  by  the  presence  of  multiple  request  replicators,  one  for  each  hardware  node  that 
supports  clients.  However,  if  all  client  req[uests  are  processed  by  a  single  replicator,  and  if  that 
replicator  forwards  requests  in  the  order  that  it  receives  them,  then  the  replicator  looks  like  the 
single  5  to  the  clients.  Thus  we  are  guaranteed  that  the  fault  tolerant  architecture  processes 
the  same  sequence  of  requests  as  the  fault  fi^  architecture,  because  the  entity  that  determines 
the  order  of  requests  is  the  environment,  which  is  the  same  in  both  models.  We  simplified  the 
problem  by  moving  request  ordering  outside  the  model  and  into  the  environment 

The  single  replicator  approach  would  not  likely  be  implemented,  because  the  replicator  (or 
rather  the  harfware  node  on  which  it  resides)  could  be  a  single  point  of  failiue;  however,  for 
modeling  purposes  we  assume  that  the  replicator  is  fault  fiee.  We  realized  an  important  advan¬ 
tage  with  the  single  replicator  we  get  ORDER  for  fiee.  It  is  also  trivial  to  demonstrate,  given 
the  design  of  R  and  the  fact  that  only  R  transmits  requests  to  the  replicas,  that  Agreement  is 
satisfied. 

Note  that  we  solved  a  slightly  different  problem  than  Schneider.  He  focused  on  practical 
implementations  for  satisfying  ORDER.  Each  of  his  order  protocols  includes  a  stability  test  to 
determine  the  next  request  to  process,  and  he  proved  that  the  test  is  sufficient.  We  avoided 
stability  tests  by  letting  the  environment  determine  the  request  sequence. 
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The  trickiest  problem  for  the  voter  is  vote  synchronization,  i.e.,  ensuring  that  the  tabulated 
result  is  based  on  a  set  of  votes  that  are  aU  resi>onses  to  the  same  request.  Communication 
delays  or  other  problems  may  prevent  some  votes  for  a  particular  recjuest  from  reaching  the 
voter  in  a  timely  manner.  Since  we  assume  nothing  about  the  vote  itself  the  voter  must  rely 
on  other  information  for  synchronizatiorL 

A  voting  session  occurs  when  the  voter  receives  a  sufficient  number  of  votes  (as  determined  by 
the  failure  dass)  for  a  particular  request.  An  obsolete  vote  is  a  vote  that  misses  its  intended 
voting  session.  The  synchronization  algorithm  is  very  simple.  A  counter  is  associated  with  each 
voting  replica.  When  the  voter  receives  enough  votes  to  constitute  a  voting  session,  it  notes 
which  replica(s)  did  not  vote  and  increments  the  coxinter  associated  with  that  replica.  When 
a  replica  votes  and  its  counter  is  greater  than  zero,  that  vote  is  discarded  and  the  counter  is 
decremented. 

There  are  several  constraints  on  the  fault  tolerant  model: 

■  It  must  he  configured  properly.  In  other  words,  the  shared  interfaces  must  be  assigned 
between  components  such  that  communication  occurs  only  as  we  require  it. 

■  Ml  appropriate  components  must  agree  on  the  failure  doss.  The  fault  generators  and  the 
voter  must  agree  whether  the  failure  dass  is  fail-stop  or  Byzantine. 

■  There  may  not  be  too  many  ^active*  fault  generators  for  the  failure  class.  We  allow  at  most 
two  faults  in  the  fail-stop  case  and  only  one  feult  in  the  Byzantine  case. 

■  The  receive  interface  and  send  interface  for  S  in  the  fault  free  model  must  correspond  to 
the  receive  interface  for  R  and  the  send  interface  for  V,  respectively,  in  the  fault  tolerant 
model.  This  constraint  is  necessary  to  prove  that  ffie  fault  tolerant  model  implements  the 
fault  free  model. 

Next,  we  considered  the  proof  that  our  fault  tolerant  model  is  indeed  fault  tolerant,  i.e.,  it 
behaves  like  a  fault  fi^e  system  in  the  presence  of  faults.  The  argument  is  divided  into  two 
obligations: 

1.  the  fault  tolerant  system  only  allows  the  behaviors  allowed  by  the  fault  iree  system,  and 

2.  the  fault  tolerant  system  allows  all  behaviors  that  the  fault  6^  system  allows. 

Obligation  1  is  stated  formally  as 

implements{compose{{R,  51,  S2,  S3,  FI,  F2,  F3,  V'}),  5)  (1) 

That  is,  every  behavior  allowed  by  oompose({F,  51, 52,  S3,  FI,  F2,  F3,  V})  is  allowed  by  5.  This 
proof  was  broken  further  into  two  subproofs: 

1.  (Initial  State)  Show  that  every  initial  state  of  compose{{R,  51, 52, 53,  FI,  F2,  F3,  V})  is 
allowed  by  5. 

2.  (Steps)  Show  that  eveiy  transition  allowed  by  compose{{Ry  51, 52, 53,  FI,  F2,  F3,  K})  is 
allowed  by  5. 

These  proofs  rely  on  constraints,  supplied  by  the  refinement  mapping,  that  define  a  state  of  5 
corresponding  to  each  state  of  compose{{Ri  51, 52, 53,  FI,  F2,  F3,  V}).  The  initial  state  proof  is 
satisfied  easily  by  relating  the  external  interfaces  of  the  two  models  and  considering  the  init  of 
Fand 
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The  steps  proof  is  more  challenging.  The  goal  of  the  steps  proof  is  to  demonstrate  that  every 
state  transition  allowed  by  the  fault  tolerant  model  is  also  allowed  by  the  fault  free  model  under 
the  interpretation  supplied  by  the  refinement  mapping.  First  we  must  show  that  any  transition 
allowed  by  the  hidd  of  every  fault  tolerant  component  is  allowed  by  the  hidd  of  5.  Then  we 
must  show  that  for  eveiy  fault  tolerant  component,  every  guar  transition  (when  restricted  to 
the  set  of  transitions  allowed  by  all  fault  tolerant  components)  is  a  transition  allowed  in  the 
fault  free  model. 

Unfoiiunately,  in  the  course  of  attempting  the  formal  proofs,  we  discovered  several  errors  in 
the  specification  that  prevent  the  proof  frem  working.  These  errors  are  in  the  form  of  omitted 
constraints  in  the  hidd  of  the  fault  tolerant  components.  The  proofs  can  be  completed  if  the 
following  missing  conditions  are  satisfied; 

■  The  unproc,  proc  and  proc.state  of  each  Si  component  are  considered  local  to  that 
component  and  can  be  changed  only  by  agents  of  that  component. 

■  No  agent  for  a  fault  tolerant  model  component  can  write  a  message  to  if  s  receive  interface. 

■  Similarly,  no  agent  for  a  fault  tolerant  model  component  can  determine  that  commumca- 
tion  over  K’s  send  interface  is  complete. 

These  corrections  would  not  be  difficult  to  make  in  the  formal  specification;  however,  there  were 
insufficient  resources  to  do  so  and  complete  the  proof  Higher  priority  was  given  to  providing  a 
detailed  informal  proof  in  the  report  [18]. 

The  second  obligation  is  stated  formally  as 

implements{S,compose{{R,  SI,  52, 53,  FI,  F2,  F3,  V}))  (2) 

In  practical  terms,  the  fault  tolerance  proof  requirement  stated  earlier  is  imnecessarily  strong. 
Rather  than  prove  that  the  models  are  equivalent,  it  is  most  interesting  to  prove  that  the 
fault  tolerant  model  does  not  exhibit  behaviors  prohibited  by  the  fault  fr«e  model.  This  is 
sufficient  to  show  that  critical  properties  demonstrated  for  fault  fr«e  are  satisfied  by  the  much 
more  complicated  fault  tolerant  architecture.  Other  methods,  such  as  testing,  can  be  used 
to  demonstrate  that  the  fault  tolerant  model  exhibits  a  non-trivial  subset  of  the  behaviors 
permitted  by  the  fault  fr^ee  model.^^ 

Finally,  we  considered  the  application  of  our  model  to  a  simple  example:  enforcers  and  deciders. 
We  argued  that  enforcers  are  like  the  clients  of  our  fault  tolerant  model,  and  deciders  are  valid 
instances  of  5.  Thus,  faults  in  the  deciders  could  be  tolerated  by  replicating  the  deciders. 


6.2.2  TLS  Modification  Approach 

For  the  second  phase  of  this  task,  we  modified  the  architecture  described  in  the  TLS  to  be  fault 
tolerant.  We  introduced  a  replicator  R  and  a  voter  V,  and  we  replicated  the  potentially  fatdty 
NS.  The  modified  architecture  is  illustrated  in  Figure  3. 

If  the  client  C  wishes  to  send  a  message  to  client  C  on  a  different  node  (kernel),  it  submits  the 
message  on  its  interface  with  the  kernel  K,  using  its  local  name  for  C".  In  a  fault  free  system, 
K  would  remap  Cs  local  name  for  C'  into  a  port  to  which  a  network  server  NS  is  listening. 

^^Tliere  is  no  possible  refinement  mapping  in  this  direction  since  multiple  fault  tolerant  states  correspond  to  each 
fault  free  state.  Hius,  a  formal  proof  of  this  case  within  the  framework  is  not  possible.  If  quantification  were  included 
in  the  framework,  the  proof  would  be  possible  in  principle,  but  probably  very  difiScult. 
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Figure  3:  Fkult  Tolerant  TLS  Architecture 

The  NS  would  forward  the  message  over  the  network  to  an  NS  on  the  node  shared  by  C'. 
This  NS  will  submit  the  message  to  its  kernel  using  its  own  local  name  for  C.  The  receiving 
K  would  place  the  message  on  a  port  to  which  C  is  listening.  (For  a  more  thorough  discussion 
of  communication  in  the  TLS,  see  the  TLS  report  [15].) 

In  a  fault  tolerant  system,  however,  K  remaps  all  of  C"s  local  names  into  ports  to  which  the 
replicator  R  is  listening.  R  then  copies  the  message  (via  K)  to  three  different  NSs.  Each 
NS  transmits  the  message  over  an  N.  At  th.e  receiving  node,  at  most  three  NSs  receive  the 
message.  Each  NS  forwards  its  message,  via  the  receiving  K,to  a  different  port  to  which  the 
voter  V  is  listening.  V-'  determines  the  proper  response  and  submits  the  message,  via  K,  to  the 
client  C'. 

In  the  unmodified  TLS,  dients  may  also  exchange  send  and  receive  rights,  and  the  kernel 
anH  network  servers  are  responsible  for  configuring  the  desired  communication  path.  Unfor¬ 
tunately,  the  algorithm  is  complicated  significantly  by  the  replication  of  the  network  servers 
nnH  by  the  introduction  of  the  replicator  and  voter.  Due  to  the  limited  scope  of  this  effort, 
we  ass\imed  that  the  communication  paths  are  in  a  steady  state  and  that  only  ordinary  data 
messages  are  passed  between  clients  in  the  modified  TLS. 

Instead  of  introducing  a  separate  fault  generator  for  each  NS  replica,  we  modified  the  network 
component  to  exhibit  controlled  faults.^^  If  a  sender-side  network  server  is  deemed  faulty,  the 
associated  network  component  will  exhibit  faulty  behavior.  We  assume  that  all  receiver-side 
network  servers  are  fault  free. 

Our  task  was  divided  into  three  subtasks: 

■  Specify  R  «nd  V  in  the  context  of  the  TLS. 

R  and  V  here  are  slightly  different  from  the  corresponding  components  in  the  proof-of- 
concept  task,  because  the  communication  interface  here  is  more  complex.  Both  compo¬ 
nents  will  use  the  kernel  interface  for  all  communication. 

■  Modify  N  to  generate  new  faxilts  in  controlled  conditions. 

Currently,  N  has  two  behaviors:  it  either  transmits  messages  successfully  or  it  randomly 
loses  them.  We  needed  to  add  a  new  behavior,  the  ability  to  modify  a  message,  and  we  had 
to  control  when  these  behaviors  occur.  As  in  the  proofiof-concept  task,  we  designated  a 
subset  of  N  components  to  be  faulty  according  to  the  failure  class  (faiLstop  or  Byzantine). 
N  exhibits  faults  whenever  the  associated  sender-side  NS  is  considered  faulty. 

■  Constrain  the  global  state  as  required  for  fault  tolerance. 

network  in  tKe  unmodified  TLS  indudes  faulte,  but  they  occur  nondeterminiBtically.  We  needed  to  ensure  that 
certain  networks  (actually  network  aervera)  are  fault  free. 
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6.3  Accomplishments 

The  proof-of-concept  demonstrated  that  the  composition  framework  is  a  practical  tool  for  ana¬ 
lyzing  fault  tolerance  pro|)erties  in  reEil  systems.  For  example,  we  enhanced  S  to  allow  faults 
without  5;  instead,  we  composed  it  with  a  fault  generator.  The  oomp>onent  spec¬ 

ification  clearly  distinguishes  the  assertions  that  a  com|X)nent  makes  about  itself  fix)m  the 
assumptions  it  makes  about  its  environment.  Thus,  the  relationships  between  components 
are  more  obvious.  This  quality  was  particularly  important  for  sx)ecifying  the  commumcation 
model.  The  only  limitation  is  that  the  framework  did  not  support  the  proof  that  the  fault  free 
model  is  a  refinement  of  the  fault  tolerant  model,  so  we  demonstrated  that  result  mfonnally. 
However,  this  limitation  is  a  problem  for  refinement  mappings  generally,  not  just  with  ^e 
framework.  Performing  a  refinement  proof  without  a  refinement  mapping  requires  reason! 
directly  about  infinite  sets  of  infinite  sequences,  which  can  be  very  difficult.  Supporting  this 
type  of  proof  would  also  add  significant  complexity  to  the  framework,  and  the  dubious  benefits 
do  not  justify  the  effort  required. 

In  the  proof-of-concept,  we  simplified  the  models  whenever  possible,  for  example: 

■  There  are  exactly  three  replicas,  instead  of  an  aibitraiy  number. 

■  The  single  rephcator  iZ  is  a  convenient  abstraction  for  the  recjuest  order  protocols  described 
by  Schneider. 

■  The  voter  V  uses  a  simple  exactimatch  voting  strategy. 

■  The  communication  model  is  based  on  a  shared  interface. 

■  The  rephcas  and  S  invoke  the  same,  undefined  function:  processjnsg.  We  assime 
nothing  about  processjnsg  so  that  almost  any  processing  function  is  an  instance  of  it. 

We  adopted  most  of  these  simplifications  for  the  TLS  modification  task,  and  we  added  new 
simplifications  as  necessary: 

■  We  assiime  that  only  ordinary  data  messages  are  passed  through  the  system,  i.e.,  no 
rights  BTe  passed  between  cUents. 

■  We  compromise  on  a  “partially  fad-stop”  network  component.  In  the  existing  network 
component  specification,  a  non-faulty  network  would  never  do  anything  whereas  a  faulty 
network  could  destroy  messages.  This  notion  is  inconsistent  with  the  concept  of  a  fad- 
stop  system  in  which  a  non-faulty  component performs  correct  operations  and  a  faulty  one 
does  nothing.  Rather  thnn  change  the  network  component  into  a  more  active  entity,  we 
leave  the  possibility  that  correct  data  might  sometimes  be  available  over  a  faulty  network 
replica  nuH  other  times  be  absent. 

■  We  recognize  that  we  cannot  enforce  FIFO  message  delivery  in  th.e  current  network 
component  as  specified,  so  we  assume  that  the  network  component  wdl  be  implemented 
to  e^orce  the  requirement. 


6.4  Lessons 

This  task  demonstrated  that  the  composition  fiamework  lets  us  separate  concerns  in  the  spec¬ 
ification.  Specifying  the  replicator,  voter  and  fault  generator  as  separate  components  in  the 
proof-of-concept  kept  the  models  veiy  general.  It  also  meant  fewer  changes  to  the  TLS,  since 
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most  of  the  new  behaviors  could  be  specified  within  separate  components.  Most  existing  TLS 
theories  were  not  changed. 

We  also  realized  significant  savings  by  letting  a  single  replicator  abstract  the  various  message 
ordering  algorithms  described  by  Schneider  [11],  As  is  typical  in  research  projects,  we  explored 
many  ‘‘dark  alleys”.  Before  realizing  the  opportunity  of  a  single  replicator,  we  spent  much  time 
considering  which  message  ordering  algorithms  to  model  and  exploring  modeling  approaches. 
We  also  considered  using  one  of  the  communication  mechanisms  in  the  TLS  (i.e.,  either  the  ker¬ 
nel  or  the  box  manager)  for  the  proof-of-ooncept  task.  However,  these  mechanisms  introduced 
more  overhead  than  we  desired. 


6.5  Future  Work 

While  we  argued  informally  in  the  proof-of-concept  task  that  the  fault  tolerant  model  behaves 
like  a  fault  free  model,  it  would  have  been  nice  to  complete  the  proof  using  the  composition 
framework.  It  would  have  also  proved  interesting  to  mc^el  one  of  Schneider^s  message  order¬ 
ing  algorithms.  Both  the  proof-of-concept  and  the  TLS  modification  could  be  generalized  by 
allowing  an  arbitrary  number  n  of  replicas.  The  model  would  define  t  as  the  number  of  allowed 
faults,  and  n  would  be  function  oft,  according  to  the  failure  dass.^^  We  settled  on  three  replicas 
because  it  was  not  necessary  to  burden  the  model  with  the  additional  complexity  in  order  to 
satisfy  our  goeils. 

The  modified  TLS  could  be  improved  in  the  following  ways: 
m  Add  support  for  the  passing  of  send  and  receive  rights. 

■  Modify  the  network  component  to  exhibit  pure  fail-stop  behavior  and  to  support  FIFO 
communication. 

In  subsequent  applications  of  the  framework,  we  have  realized  additional  areas  for  improve¬ 
ment.  For  example,  the  proof-of-concept  specification  could  be  generalized  by  adopting  a 
requirements-oriented,  rather  than  design-oriented,  specification  approach. 


^^For  an  example  of  a  specification  of  tliis  style,  see  the  CSS  TLS  [15]. 
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Section  ^ 


Policy  Composition 


7.1  Goals 

The  policy  composition  task  explored  how  to  incorporate  prior  work  on  pKjhcy  composition  into 
the  CSS  composition  end  refinement  framework.  The  goals  of  this  effort  were  to: 

■  extend  the  framework  to  provide  for  composable  noninterference  analysis,  and 

■  study  the  composition  of  differing  security  policies 

Some  types  of  security  policies  can  be  represented  as  Abadi-Lamport  properties.  For  example, 
access  control  policies  such  as  Bell-LaPadula  security  can  be  represented  as  safety  properties 
asserting  that  all  transitions  that  occur  are  consistent  with  the  access  control  policy.  For  these 
policies,  the  existing  CSS  framework  is  sufficient  since  it  provides  machinery  for  reasoning 
about  Abadi-Lamport  properties  in  general.  However,  one  conunonly  used  tyjre  of  security 
pohcy,  namely  information  flow  pohdes,  cannot  be  addressed  rising  Abadi-Lamport  properties. 
The  goal  of  this  effort  is  to  investigate  how  information  flow  policies  can  be  addressed  within 
the  CSS  framework. 

7.1.1  Information  Flow  Policies 

The  difference  between  an  access  control  policy  and  an  information  flow  policy  is  somewhat 
subtle.  The  original  motivation  for  information  flow  policies  was  to  address  the  covert  channel 
issue  in  multilevel  secure  (MLS)  systems  [8].  A  common  example  of  a  covert  channel  is  the  use 
of  file  access  times  in  Unix  to  signal  informatioiL  Fach  file  has  associated  with  it  an  access 
time  indicating  the  last  time  the  file  was  read.  An  MLS  version  of  Unix  would  check  to  ensure 
that  the  process  reading  a  file  is  at  or  above  the  level  of  the  file  before  allowing  the  read  to 
proceed.  In  the  case  of  a  high  level  subject  reading  a  low-level  file,  this  MLS  check  would  allow 
the  high  level  subject  to  change  the  access  time  for  the  low-level  file  as  a  side-effect  of  reading 
the  file.  Even  though  the  high-level  read  of  a  low-level  file  is  allowed  by  the  Bell  LaPadula 
access  control  policy,  the  downward  flow  of  information  as  a  side  effect  is  undesirable. 

Information  flow  policies  were  developed  to  address  the  covert  information  flows  resulting  from 
side  effects.  In  a  system  satisfying  a  flow  policy,  there  should  be  no  such  covert  flows.  A  variety 
of  such  policies  have  been  developed,  but  we  chose  to  focus  on  McCullough’s  Restrictiveness  [7] 
nrtrt  Rushby’s  Noninterference  [10].  At  the  heart  of  both  policies  is: 

■  for  each  system  event  e,  a  mapping  to  a  security  domain  //(e), 

■  functions  inp  and  out  that  test  whether  events  are  inputs  or  outputs, 

■  a  flow  relation  dj  d-^  indicating  when  information  is  permitted  to  flow  from  a  security 
domain  di  to  a  domain  di, 

B  for  each  domain  d  an  equivalence  relation  indicating  when  two  states  appear  identical 
from  the  standpoint  of  d 
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From  tbese  constructs,  security  requirements  such  as  the  following  are  constructed:^^ 

■  mp(e)  A  {L{€)i^  d)  A  leadsJo{sti,€){si2)  ^2 

■  inp{e)  A  {L{e)  d)  A  leads Jx){sti,  €){st2)  A  sii  sts  A  sti  «l(c)  ^3 

=:>  35^4  :  st2  st4  A  leods Jo{st 3 ,  e){st 4) 
m  out{e)  A  leadsJ^o{sii,e)(si2)  A  sii  siz 

=>  3b  :  out{b)  A  (e)  fc  A  ^2  ^d  A  iecwis_to(s/3, 6)(s<4)^^ 

Here,  leads  Jto{  s/ 1 ,  e)( ^ 2 )  indicates  that  event  e  can  cause  a  transition  from  st  1  to  st  2 .  The  actual 
security  requirements  for  Restrictiveness  snd  Noninterference  vary  from  the  above  depending 
on  whether  the  system  specification  allows  nondetenninism  and  whether  the  flow  relation  is 
transitive.  A  system  allows  nondetenninism  if  the  same  input  event  and  starting  state  can 
lead  to  more  thsn  one  resulting  state.  A  flow  relation  is  transitive  if  whenever  flow  is  allowed 
from  di  to  ^2  and  from  d2  to  da,  then  flow  is  also  allowed  from  di  to  da. 

The  reason  information  flow  policies  are  not  Abadi-Lamport  properties  is  that  Abadi-Lamport 
properties  are  simply  sets  of  component  behaviors.  The  above  security  requirements  do  not 
uniquely  define  a  set  of  component  behaviors.  Instead  they  comprise  a  test  that  can  be  per¬ 
formed  on  a  set  of  behaviors  to  determine  whether  the  associated  system  is  secure.  This  has 
led  people  to  refer  to  information  flow  policies  as  “properties  of  properties”.  In  any  case,  the  key 
point  is  that  they  are  not  Abadi-Lamport  properties  and  hence  a  different  approach  is  needed 
to  reason  about  the  composition  of  information  flow  policies. 


7.2  Approach 

Restrictiveness  has  previously  been  shown  to  be  composable  in  that: 

If  each  system  in  a  collection  S  satisfies  Restrictiveness,  then  the  composite  of  the 
systems  in  5  also  satisfies  Restrictiveness. 

This  is  a  powerfril  result  in  that  it  allows  anal3^is  to  be  done  on  individual  comi)onents  and 
then  extended  to  the  composite  system. 

Our  general  approach  for  the  policy  composition  work  consisted  of  the  following  steps: 

■  Incorporate  Restrictiveness  into  the  CSS  framework. 

■  Show  that  other  information  flow  policies  are  a  si>edal  case  of  Restrictiveness. 

Since  Restrictiveness  is  composable  with  itself  any  other  policy  that  is  a  special  case  of  Re¬ 
strictiveness  can  be  composed  with  Restrictiveness.  The  resulting  composite  system  will  satisfy 
Restrictiveness. 

The  particular  challenges  to  accomplishing  this  approach  were: 

Such  requirements  are  commonly  referred  to  ae  \mwinding  conditionfl  for  the  flow  policy  rather  thAn  the  flow  policy 
itaelf.  Usually  the  flow  policy  itself  requires  that  ecpiivalent  event  secpiencee  lead  to  equivalent  states.  The  imwinding 
conditions  reduce  such  policy  statements  about  sequences  of  events  to  statements  about  individual  events.  Performing 
analysis  with  respect  to  the  unwinding  conditions  is  generally  much  easier  than  performing  analysis  with  respect  to 
the  flow  policy  itself. 

'®Here,  fc  is  an  event  sequence  and  out  and  leads  J,o  are  the  obvious  extensions  from  functions  on  events  to  functions 
on  event  sequences.  The  application  of  to  event  sequences  indicates  whether  each  flow  contains  the  same  set  of 
allowed  flows. 
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■  The  type  of  composition  with  respect  to  which  Restrictiveness  is  composable  is  different 
than  the  CSS  notion  of  composition. 

■  Restrictiveness  assumes  a  transitive  flow  relation.  Thus,  generalizations  might  be  re¬ 
quired  in  Restrictiveness  to  ensure  intransitive  information  flow  pohcdes  are  a  special 
case  of  Restrictiveness. 

7.2.1  Detailed  Approach 

To  extend  the  framework,  we  defined  a  system  to  be  a  structure  with  fields: 

■  cmp  —  a  CSS  component, 

■  inp  —  a  set  of  agents  denoting  events  that  are  S5atem  inputs, 

■  vws  —  a  mapping  fram  security  domains  to  equivalence  relations  on  states, 
m  D  —  a  relation  indicating  whether  flow  is  allowed  fiam  di  to  d2,  and 

m  L  —  a  mapping  fram  agents  to  security  domains.^ ^ 

Since  information  flow  policies  are  generally  stated  in  terms  of  events  and  states,  we  needed 
a  way  to  represent  events  within  the  CSS  firamework.  Events  in  information  flow  pohcdes  sue 
used  to  label  state  transitions,  while  the  CSS  framework  labels  state  transitions  with  agents. 
Equating  events  with  agents  is  the  natural  approach  to  use  in  incorporating  information  flow 
pohcdes  into  the  framework. 

With  these  constructs,  the  formalization  of  Restrictiveness  for  systems  was  simply  a  matter 
of  translating  the  formalization  in  the  hterature.  We  next  attempted  to  demonstrate  that 
Restrictiveness  is  composable  with  respect  to  the  framework  definition  of  composition.  As 
mentioned  earher,  the  CSS  notion  of  composition  is  different  than  the  type  of  cemposition  with 
respect  to  which  Restrictiveness  has  previously  been  shown  to  be  composable.  The  primary 
difference  is  that  the  other  type  of  comjiosition  assumes  that  systems  have  disjoint  state  spaces. 
The  motivation  for  this  is  that  events  represent  messages  passed  between  loosely  coupled 
systems.  In  contrast,  agents  in  the  CSS  framework  are  more  to  denote  resixmsibility  for 
a  transition  to  denote  information  being  communicated;  communication  is  assumed  to 
occur  through  shared  state  information. 

The  significance  of  this  difference  poses  a  problem  when  showing  that  security  requirements  of 
the  form  illustrated  in  Section  7.1.1  are  composable.  Then,  the  requirements  are  assumed  to 
hold  for  each  of  a  collection  of  systems  and  the  goal  is  to  show  the  composite  of  those  systems 
satisfies  the  requirements.  Some  of  the  requirements  assert  the  existence  of  a  st4  satisfying 
certain  properties.  Unfortunately,  the  fact  each  individual  system  satisfies  the  requirements 
only  guarantees  the  existence  of  a  set  of  st^’s  each  of  which  satisfies  the  desired  properties  for 
one  of  the  individual  systems.  To  prove  composability,  a  st^  must  be  exhibited  that  satisfies 
the  properties  for  the  composite  system.  Essentially,  this  requires  exhibiting  a  single  st^  that 
satisfies  the  necessary  properties  for  each  system.  In  Restrictiveness’  version  of  composition, 
the  desired  st^  is  simply  the  merger  of  the  st4’s  known  to  exist  for  each  system.  Since  the  state 
spaces  are  independent,  this  merger  is  well-defined.  When  the  state  spaces  are  not  independent, 

the  PVS  itself,  we  refer  to  “security  domains"  as  levels.  This  is  an  artifact  of  the  work  initially  being  based  on 
MLS  policiefi.  Also  note  that  D  and  L  are  actually  generic  parameters  to  the  system  theory  rather  than  fields  of 
system  structure.  The  only  real  significance  to  this  distinction  is  that  D  and  L  must  be  static  throughout  the  execution 
of  a  system. 
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some  way  is  needed  to  merge  the  st^s  known  to  exist  for  the  individual  components  into  a  st^ 
acceptable  to  all  components. 

The  only  solution  we  develop^ed  to  this  type  of  problem  was  to  add  assumptions  about  the  set 
of  systems  being  comi)osed.  Thus,  the  composition  theorem  was  of  the  form: 

If  sys^sei  satisfies  certain  hypotheses  and  each  element  of  sys^set  is  Restrictive,  then 
the  composition  of  the  elements  in  sys^set  is  Restrictive. 

This  is  a  less  desirable  composition  result  than  that  for  Restrictiveness  since  the  additional 
hypotheses  mast  be  considered  each  time  Restrictiveness  of  components  is  to  be  lifted  to  Re¬ 
strictiveness  of  the  composite.  Note,  however,  that  when  the  Restrictiveness’  simplifying  as¬ 
sumption  about  state  space  indep>endence  is  made,  the  proof  of  the  additional  hypotheses  is 
trivial.  This  simplification  is  only  possible  when  specifications  are  written  in  a  loosely  coupled 
manner.  For  more  tightly  coupled  components,  the  additional  hypotheses  are  a  concern,  but 
then  the  original  form  of  Restrictiveness  cannot  even  be  used. 

As  an  alternative,  we  also  considered  a  strictly  stronger  policy  definition  based  onevent  dosu'ne, 
A  system  is  said  to  satisfy  event  closure  if: 


■  leadsJto[sti,e){si2)  A  si\  «i,(c)  stz  A  st^  ^L{t)  ^4 
=>  leaxisJx){st:i,e){st^) 

In  other  words,  whenever  {six,  s/2,  c)  »nd  (s/3, 5/4,  e)  denote  equivalent  transitions  with  respect 
to  then  if  one  transition  is  valid  in  the  system  the  other  transition  must  be  valid,  too. 

We  define  a  System^"^  to  be  a  system  that  satisfies  the  unwinding  condition  dealing  with  ‘high” 
inputs^  ^  (known  as  the  Local  Bespect  condition  in  Rushbys  work)  and  satisfies  event  closure. 
We  showed  the  conjunction  of  these  conditions  is  composable.  This  means  that  a  composition 
of  Systems  is  itself  a  System.  Event  closure  implies  the  unwinding  condition  dealing  with 
“low  inputs”  (known  as  the  Step  Consistency  condition  in  Rushby’s  work).  So,  the  fact  that 
composition  preserves  Systems  results  in  a  policy  that  is  very  similar  to  Restrictiveness  yet 
composable  using  our  definition  of  composition.  If  event  closure  is  an  acceptable  i)olicy  for 
an  analyst,  the  analyst  could  use  event  closure  and  not  need  to  prove  additional  hypotheses 
hold  when  lifting  event  closure  of  components  to  a  composite  system.  However,  neither  the 
Local  Respect  condition  nor  event  closure  subsumes  Restrictiveness’  requirement  on  outputs 
and  consequently  they  alone  might  not  be  sufi&dent  security  requirements. 

A  third  option  explored  in  this  work  is  Restrictive  Systems — thst  is,  systems  that  satisfy  all 
the  requirements  of  McCullough  restrictiveness  and  satisfy  event  closure.  This  definition  of 
security  is  strictly  stronger  th^n  McCuUoxigh  Restrictiveness.  The  associated  comi)osability 
theorem  for  Restrictive  Systems  has  fewer  proof  obligations  than  does  the  theorem  for  restric¬ 
tive  systems.  Thus,  this  approach  represents  a  compromise  between  the  first  two  approaches. 

Next,  we  demonstrated  that  Rushby^s  transitive  noninterference  is  simply  a  deterministic  ver¬ 
sion  of  Restrictiveness.  This  ensures  that  as  long  as  each  component  system  is  either  restrictive 
or  noninterfering,  then  the  composite  is  restrictive  as  long  as  the  additional  hypotheses  hold. 

Finally,  we  investigated  the  generalization  of  Restrictiveness  to  incorporate  intransitive  poli¬ 
cies.  Although  it  was  relatively  straightforward  to  incorporate  Rushby^s  concepts  for  intransi¬ 
tive  policies  into  the  definition  of  Restrictiveness,  we  were  unable  to  demonstrate  the  resulting 

*®Note  the  capitalization. 

By  a  high  input,  we  mean  an  input  event  whose  aecurity  domain  ie  not  permitted  to  communicate  with  the  domain 
with  respect  to  which  the  view  is  being  taken. 
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generalization  was  composable.  We  were  successful  in  demonstrating  that  the  Local  Respect 
and  Step  Consistency  conditions  are  composable  (once  again  under  some  additional  hypotheses 
on  the  components  being  composed).  However,  we  were  not  able  to  complete  the  proof  that 
the  unwinding  condition  deali^  with  system  outputs  is  composable  before  running  out  of  time 
on  the  program.  This  proof  is  the  hardest  part  of  proving  the  unwinding  conditions  are  com¬ 
posable,  so  we  really  made  little  progress  on  demonstrating  the  generalization  for  intransitive 
pohdes  is  composable. 

Although  most  applications  of  information  flow  policies  in  practice  have  been  with  respect  to 
transitive  (MLS)  policies,  having  theories  of  intransitive  policies  would  be  useful.  Example 
applications  include  the  following: 

■  Consider  an  MLS  system  that  contains  certain  trusted  processes  that  have  privileges 
allowing  them  to  downgrade  information  It  is  not  possible  to  prove  a  transitive  noninter¬ 
ference  policy  because  the  downgrading  of  information  would  violate  the  pK)licy.  However, 
an  intransitive  flow  relation  could  be  defined  that  allows: 

-  any  information  flow  upward  in  level, 

-  any  information  flow  to  a  trusted  process,  and 

-  any  information  flow  fiom  a  trusted  process. 

Rushbys  intransitive  noninterference  with  this  flow  relation  would  require  that  infor¬ 
mation  only  flow  downward  in  level  if  it  goes  through  a  trusted  process.  Analysis  with 
respect  to  this  p>olicy  would  identify  any  downgrades  that  bypass  the  trusted  processes. 

■  Consider  an  assured  pipeline.  In  other  words,  consider  a  system  that  requires  information 
to  flow  through  certain  stages.  As  a  specific  example,  consider  a  firewall  proxy  protecting 
internal  systems  from  the  internet.  An  intransitive  flow  relation  could  be  defined  that 
allows: 

“  any  information  flow  from  the  internet  to  the  proxy,  and 
“  any  information  flow  from  the  proxy  to  the  internal  systems. 

Analysis  with  respect  to  this  system  could  detect  flaws  that  allow  the  proxy  to  be  bypassed. 

The  naturalness  of  intransitive  policies  to  state  such  real-world  policies  is  a  strong  argument 
for  developing  theories  to  support  intransitive  policies. 


7.3  Accomplishments 

The  positive  results  of  the  program  are: 

■  We  were  able  to  formalize  infoimation  flow  policies  within  the  framework. 

■  We  were  able  to  prove  some  composability  results  for  these  flow  policies. 

■  We  demonstrated  transitive  noninterference  is  a  special  case  of  Restrictiveness. 

■  We  developed  a  generalization  of  Restrictiveness  that  subsumes  intransitive  noninterfer¬ 
ence.  We  also  completed  small  parts  of  the  proof  of  composability  of  this  definition 
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■  We  hypothesked  that  any  information  flow  policy  can  be  partitioned  into  a  purely  transi¬ 
tive  information  flow  policy  plus  a  purely  intransitive  information  flow  policy.  This  would 
provide  a  nice  “normal  form”  for  policies.  We  sketched  a  proof  that  this  decomposition  is 
always  possible,  but  did  not  spend  much  time  verifying  the  details  of  the  proof 

Limitations  of  the  results  of  the  program  are: 

■  We  were  unable  to  complete  the  composability  proof  for  the  generalization  of  Restrictiye- 
ness.  This  means  that  our  composition  result  does  not  currently  support  intransitive 
policies.  We  do  not  yet  know  whether  the  desired  result  is  improvable  or  whether  ad¬ 
ditional  time  would  allow  us  to  complete  the  proof  We  have,  however,  noted  the  need 
to  change  the  proof  strategy  based  on  differences  in  how  equivalent  event  sequences  are 
defined  in  the  transitive  and  intransitive  cases. 

Sequence  equivalence  is  defined  in  terms  of  event  purging  which  removes^  &om  the  se¬ 
quence  those  events  that  are  prohibited  from  communicating  with  the  domain  of  interest. 
In  the  transitive  case,  the  puigeability  of  an  event  depends  on  only  the  label  of  the  event. 
In  contrast,  purgeabUitj'  in  the  intransitive  case  depends  on  what  events  occur  later  in 
the  sequence.  To  darifyr  this  distinction,  suppose  flow  is  allowed  from  A  Xo  B  and  from 
B  to  C,  «Tifl  events  a  and  b  have  labels  A  and  B.  Event  a  is  purgeable  with  resp>ect  to  C 
in  the  sequence  (a)  since  there  is  no  path  from  ^  to  C  in  the  remailer  of  the  sequence. 
However,  since  a  is  a  path  from  Ato  B  and  6  is  a  path  flom  B  to  C,  o  is  nonpiu^eable  with 
respect  to  C  in  the  sequence  (a,  b). 

The  significance  of  this  difference  is  in  piecing  together  an  acceptable  output  sequence  b 
for  the  composability  proof  for  the  condition  on  system  outputs.  The  proof  proceeds  by 
induction  htiH  considers  a  sequence  ag  o  a  in  the  inductive  step.  Since  the  requirement 
on  outputs  is  assumed  to  hold  for  individual  sj^tems,  it  is  possible  to  obtain  a  sequence 
bi  that  is  equivalent  to  {og).  The  inductive  hyjiothesis  can  be  used  to  obtain  a  sequence 
62  that  is  equivalent  to  a.  In  the  transitive  case,  61  o  62  can  be  used  for  b.  The  context 
insensitivity  of  purging  means  that  concatenation  of  equivalent  sequences  results  in 
equivalent  sequences.  The  failure  of  this  property  to  hold  for  intransitive  purging  means 
a  different  strategy  must  be  used  for  the  proof. 

■  Qur  restrictiveness  composition  result  contains  additional  hypotheses  on  the  systems 
being  composed.  This  is  undesirable  because  it  requires  additional  analysis  to  be  per¬ 
formed  whenever  there  is  a  need  to  lift  the  Restrictiveness  of  individual  components  to 
the  Restrictiveness  of  the  composite.  The  additional  analysis  should  be  trivial  in  cases 
when  McCullough  Restrictiveness  is  applicable.  So,  our  formulation  essentially  contains 
McCullough  Restrictiveness  as  a  special  case. 

■  Our  event  closure  composition  result  does  not  contain  additional  hypotheses,  but  is  strictly 
incomparable  to  Restrictiveness.  The  event  closure  property  itself  is  strictly  stronger  than 
Restrictiveness’  Step  Consistency.  However,  Restrictiveness’  requirement  on  outputs  is 
not  addressed  by  event  closure.  This  makes  it  unclear  whether  event  closure  and  the 
Local  Respect  conditions  alone  are  adecpoate  properties  for  analyzing  systems. 

■  The  Restrictive  System  result  is  probably  the  best  of  the  three  composability  results.  Its 
definition  of  security  is  stronger  than  that  of  McCullough  and  its  proof  obligations  are 
easier  thnn  our  first  restrictiveness  composition  result. 

■  We  have  no  practical  experience  using  our  composition  results.  We  do  not  know,  for 
example,  how  difficult  it  is  to  justify  the  additional  hypotheses  present  in  the  composition 
theorems. 
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■  Finally,  we  cxmsidered  only  two  forms  of  information  flow  policies.  There  are  a  variety 
of  other  types  of  information  flow  policies.  At  present  we  have  no  idea  how  composable 
other  tyx>es  of  flow  policies  are  with  Restrictiveness  and  Noninterference.  In  retrospect, 
we  underestimated  the  amount  of  time  required  for  this  task  and  thus  did  not  budget 
enough  time  to  consider  a  wide  enough  variety  of  policies. 


7.4  Lessons 

All  lessons  learned  have  been  captured  above  in  Section  7.3. 


7.5  Future  Work 

Much  work  remains  to  be  done  in  this  area.  First,  we  need  to  sample  more  of  the  types  of 
information  flow  pohdes  in  existence  and  give  consideration  to  how  they  might  be  composed.  If 
many  of  these  policies  are  not  easily  subsumed  under  Restrictiveness,  then  the  overall  approach 
of  developing  a  general,  composable  information  flow  pohcy  must  be  abandoned  in  favor  of  a 
calculus  indicating  for  each  pair  of  policy  types  the  result  of  a  composition. 

Regardless  of  which  approach  is  found  best,  there  still  remains  much  to  do  for  each.  For 
the  unifying  policy  approach,  the  general,  composable  pohcy  must  be  developed  and  shown  to 
subsume  the  various  existing  pohdes.  In  addition,  experience  must  be  gained  regarding  how 
difficult  the  additional  hyi)otheses  in  the  composition  theorem  are  to  justify  If  the  calculus  ap¬ 
proach  is  pursued,  then  the  various  pohdes  must  be  formalized  in  the  extended  CSS  framework 
and  composition  theorems  must  be  proved  for  each  pair  of  pohcy  type.  Once  again,  practical 
experience  using  the  resulting  composition  theorems  is  needed. 
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Section  ^ 

Tool  Support 


8.1  Goals 

The  goal  of  the  tools  task  was  to  identify’  and  prototype  automated  software  tools  to  assist  in 
the  design  and  refinement  process  including  the  proofs  involved  in  applying  the  framework. 
Preference  was  given  to  adapting  existing  tools,  rather  than  creating  new  ones.  Two  primaiy 
tools  were  identified. 

■  Specification  Browser 

This  tool  assists  in  writing  and  maintaining  specifications  in  the  form  required  by  the 
framework.  The  Specification  Browser  also  aides  analysts  and  developers  in  achieving 
and  mflintiiining  consistent  coverage  in  formal  and  informal  descriptions  of  a  software 
component. 

■  Analyst’s  Assistant 

This  tool  facilitates  the  use  of  the  framework  by  analysts  new  to  PVS  and  to  the  framework. 
The  assistance  provided  comes  in  two  forms: 

-  When  possible,  automate  portions  of  proofs. 

-  Provide  analysis  hints  on  the  proof  approach  to  use  and  help  the  analyst  construct 
lemmas  facilitating  the  analysis. 

We  discuss  each  of  these  tools  in  this  section. 


8.2  Approach 

8.2.1  Specification  Browser 

The  CSS  methodology  encourages  parallel  refinement  of  the  formal  model  and  the  system  de¬ 
sign  to  a  detailed  level.  This  produces  a  stronger  link  between  the  assurance  analysis  and 
the  detailed  design,  resulting  in  a  higher  level  of  assxirance  that  the  developed  code  correctly 
implements  the  specification.  The  Specification  Browser  supports  the  CSS  methodology  by 
combining  the  formal  specification  and  the  design  description  in  the  same  document.  This 
helps  code  developers  and  assurance  engineers  provide  consistent  coverage  in  text  descrip¬ 
tion  and  formal  specifications,  strengthening  the  connection  between  assurance  and  design 
through  successive  refinement  steps.  Because  code  developers  and  assurance  engineers  work 
from  the  same  information,  there  is  an  increased  level  of  assurance.  Also,  the  Specification 
Browser  guides  specifiers  in  supplying  all  the  sections  required  for  use  in  the  oomposability 
and  refinement  fiTameworks. 

To  achieve  the  goals  of  parallel  refinement,  dose  correspondence  and  ease  of  writing  specifica¬ 
tions,  the  Specification  Browser  was  designed  with  the  following  functionality  in  mind: 

■  The  browser  has  an  understanding  of  the  structure  of  a  specification  written  for  the 
framework.  This  includes 
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-  the  kinds  of  inforznation  comm  only  included  in  a  formal  si)ecification  (e.g.,  initial 
state  requirements  and  transitions) 

-  convenient  ways  to  structure  this  information  for  use  in  a  specification  in  the  CSS 
Framework. 

■  The  browser  uses  this  understanding  to  instantiate  templates  for  documents,  sections, 
transitions,  etc.  into  which  specifiers  can  type  the  information  for  the  component  being 
specified.  The  browser  helps  link  these  templates  together  to  form  a  complete  specification 
document. 

■  The  default  structure  of  a  specification  document  will  keep  the  formal  and  informal  de¬ 
scriptions  as  close  together  as  possible  to  encoiirage  cross-checking  for  consistency. 

■  The  browser  provides  cross-referencing  and  search  functionality  that  helps  relate  the 
informal  and  formal  specifications.  For  example,  both  versions  can  be  displayed  simul¬ 
taneously,  and  regular  expression  searches  can  be  performed  in  the  formal  and  informal 
specifications  to  help  correlate  definitions  of  concepts. 

■  Since  it  is  frequently  usefiil  to  have  a  tabular  representation  of  the  behavior  of  a  compo¬ 
nent  or  a  piece  thereof^  the  browser  supports  case  coverage  (processing)  tables. 

■  To  allow  speakers  flexibility  in  the  final  appearance  and  structure  of  their  documents, 
the  order  of  sections  is  configurable. 

■  The  browser  provides  a  high-level  view  of  the  document  to  aide  navigation  throiigh  a  laiige 
specification. 

Specification  documents  produced  with  the  browser  intermingle  formal  specifications  and  text 
descriptions  of  each  component  that  is  specified.  Each  formal  specification  has  a  corresponding 
text  description.  Several  tools  are  used  to  create  these  specification  documents:  PVS,  Emacs, 
the  Specification  Browser,  I^TT^X,  and  td/tk.  The  relationship  of  some  of  these  tools  is  shown  in 
Figure  4.  The  formal  specifications  are  written  with  PVS  (Prototype  Verification  System).  The 
Emacs  display  editor  provides  the  interface  to  PVS.  Although  text  descriptions  may  be  written 
using  any  text  editor,  Emacs  can  be  customized  or  extended  using  the  builf>in  Emacs  LISP 
language.  Emacs  also  provides  some  support  for  producing  ^5^  documents.  The  Specification 
Browser  is  implemented  using  Emacs  as  a  front-end  user  interface.  The  common  interface  with 
PVS,  the  built-in  support  for  and  the  built-in  Emacs-USP  language  contributed  to  this 

decision. 

The  Specification  Browser  makes  use  of  several  template  files.  These  files  help  by  identifying  all 
the  required  and  optional  sections  for  si)ecification  documents  that  follow  the  CSS  methodology 
and  by  providing  the  "boiler  plate”  information  and  driver  files  necessary  to  produce  a  MJgjX 
document. 

The  processing  table  tool  is  written  in  td/tk.  It  provides  a  graphical  interface  for  creating 
processing  tables  that  describe  the  return  value  and  state  changes  associated  with  each  value 
of  the  relevant  Boolean  conditions  on  the  input  parameters  and  current  state.  The  processing 
table  tool  can  also  be  used  to  verify  that  all  combinations  of  Boolean  values  are  covered  by  a 
given  table.  This  tool  was  originally  developed  on  another  program  and  has  been  adapted  to 
work  with  the  Specification  Browser. 

Understanding  the  high-level  structure  of  a  specification  means  that  the  Specification  Browser 
cftTi  determine  in  which  specification  section  the  point  of  the  current  Emacs  buffer  is  located 
and  how  that  section  relates  to  others  in  the  document.  This  understanding  also  allows  the 
Specification  Browser  to  find  and  simidtaneously  display  corresponding  formal  and  informal 
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User 


Figure  4:  System-level  diagram. 


descriptions.  Also,  the  Specification  Browser  will  still  function  if  a  user  changes  the  order  of 
specification  sections  or  decides  to  omit  certain  sections  although  some  of  the  features  may 
cease  to  work. 

To  implement  this  structure  awareness,  the  Specification  Browser  uses  formatted  com¬ 
ments  inserted  in  the  specification’s  text  sections  to  uniquely  identify  each  specification  section. 
The  comments  do  not  affect  the  output  of  the  specification  document.  The  comments  are  of  the 
form 

%TLS%unique  identifying  string% 

Each  formatted  comment  indicates  the  start  or  end  of  a  specification  section  of  a  particular 
type.  There  are  formatted  comments  at  the  start  and  end  of  each  template  file  which  help 
to  identify  that  file.  For  example,  a  file  may  contain  a  component  specification  or  a  process 
transition. 


8.2.2  Analyst’s  Assistant 

Early  in  the  effort,  we  decided  the  most  reasonable  approach  to  explore  was  the  construction 
of  PVS  strategies  to  simplify  the  proof  effort.  FVS  strategies  are  essentially  LISP  programs 
that  can  be  executed  from  within  the  prover  to  access  and  manipulate  the  current  state  of  the 
theorem  being  proved.  The  underlying  PVS  prover  ensures  any  manipulations  of  the  theorem 
are  logically  sound.  The  developers  of  PVS  provide  the  strategy  facility  to  allow  others  to  extend 
the  PVS  prover  as  they  see  fit.  This  is  the  natural  approach  to  providing  analysts  automated 
support  within  the  prover. 

Unfortunately,  there  is  little  documentation  currently  available  on  how  to  construct  interesting 
strategies.  In  particular,  little  information  is  available  on  how  to  access  the  internal  structures 
representing  a  theorem.  Without  this  information,  proof  steps  cannot  be  tailored  to  fit  the  form 
of  the  current  theorem.  Part  of  this  effort,  consequently,  was  aimed  at  reverse  engineering 
the  internal  data  structures  used  to  represent  theorems.  The  LISP  command  describe  was 
the  key  to  this  part  of  the  effort.  It  displays  essentially  all  there  is  to  know  about  any  data 
structure  provided  to  it.  By  starting  with  the  variable  holding  the  current  state  of  the  theorem, 
we  were  able  to  repeatedly  use  describe  to  pick  the  structure  apart.  Examples  of  the  types  of 
things  we  were  able  to  do  include: 
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■  Test  PVS  expressions  to  see  if  tiey  satisfied  a  specific  form.  For  example,  the  frame¬ 
work  function  compJ.  denotes  the  set  of  restrictions  on  components.  For  each  component 
specified,  a  goal  of  the  form; 

-  compj(cmp) 

is  generated.  Once  a  method  is  devised  to  access  the  internal  state,  it  is  possible  to  test 
whether  the  current  theorem  is  of  a  given  form,  for  example,  compJ{J).  This  is  a  handy 
technique  for  deciding  what  type  of  requirement  is  being  proved  and  which  proof  steps 
are  appropriate. 

■  Look  up  function  definitions  in  the  database  PVS  tniilds  when  it  parses  a  specification. 
As  an  example  application,  coiisider  expanding  the  definition  of  a  component.  Typically, 
we  specily  functions  such  as  cmp^spec,  cmp^ec.base,  cmpJnit,  arid  so  on.  Upon  finding 
cmp.spec  in  the  statement  of  the  theorem,  it  is  useful  to  be  able  to  look  up  its  definition 
and  find  the  need  to  expand  cmp.spec.base.  Similarly,  it  is  useful  to  be  able  to  look  up 
the  definition  of  cmp.spec.base  and  identify  the  need  to  expand  cmpJnit.  Once  the  list  of 
functions  to  expand  is  identified,  a  proof  command  ean  be  generated  and  executed  that 
expands  exactly  those  functions. 

■  Traverse  PVS  expressions.  For  example,  given  an  expression  such  asx  =  AVa:  =  BVi  = 
C  we  were  able  to  build  a  function  that  returaed  a  list  of  the  possible  elements  for  x  (in 
this  case,  (A  B  C) . 

In  general,  our  approach  was  to  construct  a  single  stiategy  for  use  by  analysts.  This  strategy 
is  called  css  -prove.  The  general  structure  of  the  strategy  is: 

if  theorem  is  of  class  1,  then  execute  strategy  1 
else  if  theorem  is  of  class  2,  then  execute  strat^y  2 


else  if  theorem  is  of  class  n,  then  execute  strategy  n 
else  indicate  no  help  can  be  provided 

In  other  words,  css  -prove  recognizes  certain  classes  of  theorems  and  for  each  has  an  asso¬ 
ciated  proof  script  intended  to  automated  some  or  aU  of  the  proof  This  tack  was  executed  as 
level-ofreffort  so  we  simply  continued  adding  new  dasses  to  css  -  prove  until  the  budget  was 
expended.  In  addition  to  associating  proof  scripts  with  each  class  of  theorem,  we  also  associ¬ 
ated  a  help  page  with  each  class.  The  help  page  provides  a  description  of  the  dass,  suggests 
a  general  approach  to  performing  the  proof  and  indicates  theorems  *»nd  definitions  from  the 
framework  that  might  be  of  use  in  the  proof  If  the  analyst  sets  the  :  help  flag  to  t  when 
calling  css  -  prove,  then  rather  than  the  class’  proof  script  being  executed  css  -  prove  simply 
displays  the  appropriate  help  page. 

The  intent  of  this  approach  is  to  allow  the  analyst  to  use  the  css  -prove  command  whenever 
he  is  unsure  how  to  proceed.  If  the  current  theorem  is  one  of  the  recc^nized  dasses,  then  the 
strategy  can  start  the  proof  in  the  correct  direction  (and  sometimes  complete  the  proof  itself) 
or  provide  the  analyst  with  help.  For  analysts  that  know  little  about  the  framework  or  PVS, 
having  a  single  command  that  helps  them  learn  about  both  should  be  very  valuable.  Even  for 
analysts  that  are  knowledgeable  of  both  the  framework  and  PVS,  the  strategy  can  sometimes 
save  the  analyst  the  trouble  of  performing  a  tedious  proof  manually. 
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8.2.2. 1  Detailed  Approach  We  now  provide  an  example  of  what  we  mean  by  a  theorem  class, 
how  css  -  prove  recognizes  a  theorem  dass,  and  what  a  proof  script  and  help  page  look  like. 
For  this  example,  we  will  consider  theorems  of  the  form: 

impl_init ( compose ( stack_set ( ns ) ) ,  net_serv_comp (ns ) ) 

This  is  an  instance  of  a  theorem  class.  The  class  is  parameterized  by  a  set  of  implementation 
(low-level)  components  Hnd  a  specification  (high-level)  component.  In  other  words,  the  class 
has  the  following  template: 

impl_init( compose (_) ,_) 

The  first  step  in  implementing  the  proof  strategy  is  to  recognize  prover  states  that  match  this 
template.  To  do  so  we  search  the  consequent  (the  things  to  be  proven)  in  the  current  prover 
goal  looking  for  a  formtila  that  satisfies  the  following: 

■  it  is  an  apphcation  of  the  impl_init  function, 

■  it  has  two  arguments,  and 

■  its  first  argument  is  an  application  of  the  compose  function. 

The  next  step  is  to  develop  a  sequence  of  prover  commands  to  be  returned  by  the  strategy  for 
execution  by  PVS.  This  proof  strategy  is  one  of  the  more  complicated  ones  developed  under 
this  task  and  consecpiently  provides  a  good  illustration  of  the  range  of  strategies  that  can 
be  developed.  Note,  however,  that  this  particular  type  of  proof  is  too  difficult  to  completely 
automate.  Instead,  this  strategy  simply  automates  the  common  steps  that  typically  need  to  be 
taken  at  the  beginning  of  the  proof  The  hope  is  that  by  getting  the  analyst  started  in  the  right 
direction,  the  analyst  can  more  easily  complete  the  proof 

The  definition  o{  impLinit{compose{set),  cmp)  is  simply  that  inii{compose{set))  is  contained  in 
init{cmp).  The  definition  of  compose  is  such  that  inU{compose(set))  is  the  intersection  of  init{c) 
for  each  c  in  set.  So,  letting  ci,  ...,  Cn  denote  the  elements  of  set,  it  suffices  to  show  that: 

init{ci){elem)  A  init{c2){elem)  A  ...  A  init{cn){elem)  =>  init{cmp){elem)  (3) 

The  strategy  we  defined  reduces  the  initial  goal  to  this  simpler  goal.  In  addition,  it  expands  the 
definition  of  each  component  until  the  function  defining  the  init  for  the  component  is  reached. 
For  example,  if /i,  ...,/n  denote  the  functions  defining  jnt<  for  the  Cj’s  and /denotes  the  function 
defining  cmp’s  init,  then  the  strategy  reduces  the  goal  to: 

fi{elem) ...  A  fn{elem)  =>  f{elem) 

Having  the  strategy  perform  additional  proof  steps  such  as  expanding  the  definitions  of  the 
/i’s  and  /  or  perform  a  grind^°  would  be  trivial.  However,  the  one  sample  theorem  of  this 
form  that  we  attempted  was  not  provable  by  simply  grinding.  We  felt  that  the  expansion  of 
additional  functions  left  the  theorem  in  too  complex  of  a  state  to  be  a  useful  starting  point 
for  the  analyst  «nd  chose  to  stop  at  this  point.  This  trade  between  automating  as  much  as 
possible  and  providing  the  analyst  an  understandable  starting  point  is  an  issue  for  any  proofs 
that  cannot  be  completely  automated. 

Now  that  we  have  described  our  intent  for  the  strategy,  we  can  describe  its  implementation. 
The  first  step  we  take  is  to  show  that: 

^®The  grind  strategy  is  a  powerful  strategy  provided  witii  PVS  tiiat  repeatedly  expands  function  definitions  and 
performs  logical  rewrites.  This  strategy  is  powerful  enough  to  automatically  prove  simple  types  of  theorems. 
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init{compose{set))  =  {  c/em  |  init{ci){elem)  A  ...  A  init{cn){elem)  } 

We  do  this  by  coostructiDg  the  oration  of  the  above  expression  wnH  nging  it  for  a  case  split. 
The  first  case  of  the  proof  requires  proving  the  expression  true  can  be  done  iiBiT<g  a  grind. 
In  the  second  case,  we  can  assume  this  expression  holds.  After  expanding  the  appropriate 
functions,  we  see  we  can  assume  that  init{compoBe(set)){elem)  holds  for  some  elem.  Using  the 
expression  proven  in  the  first  case,  we  can  assume  c/cm  is  an  element  of  each  init{ci).  Then, 
all  that  remains  for  the  strategy  to  do  is  expand  the  Cj’s  to  get  to  the  fi’s  and  axpand  cmp  to  get 
to/. 

The  hardest  part  of  the  strategy  is  constructing  the  expression  upon  which  to  case  split.  By 
picking  apart  the  concliision,  an  expression  representing  set  can  extracted.  Using  suitable 
accessor  functions  discovered  using  describe,  the  definition  of  set  can  be  extracted.  This 
strategy  assumes  that  the  definition  is  of  the  form: 

{c|  c  =  ci  V  ...  V  c  =  c„} 

PVS  represents  such  an  expression  using  a  set*EXPR  data  structure  having  accessors 
BINDINGS  and  EXPRESSION.  In  this  case,  bindings  returns  a  singleton  list  containing  c 
and  expression  returns  c  =  ci  v...Vc  =  c„.  PVS  represents  thic  expression  using  an 
INFIX -application  structure  with  operator  OR  and  arguments  c  =  ci  andc  =  cj  V. . .  Vc  =  c„. 
A  recursive  function  was  written  to  traverse  such  an  expression  And  return  the  list  ci , . . . ,  Cn . 
Another  recursive  function  was  written  that  took  such  a  list  and  converted  it  to  an  erq)ression 
of  the  form  init(compose{set)){elem)  ^  in»t(ci)  A  ...  A  inii{cn). 

The  strategy  uses  the  PVS  strategy  branch  to  split  the  proof  into  cases.  Branch  takes  the 
form: 

(branch  (cmd)  ((cmdl)  (cmd2)  ...  (cmdm))) 

In  this  construct,  cmd,  cmdl,  ...cmdm  are  each  strategies  themselves.  The  strat^y  cmd  is 
assumed  to  break  the  current  goal  into  m  cases.  The  strategy  cmdl  is  applied  to  case  t.  Fbr  the 
strategy  being  built  here  cmd  is  the  case  split,  cmdl  is  a  sequence  of  commands  for  proving  (3), 
and  cmd 2  expands  impLinit,  subset?,  the  c,'’s  and  cmp. 

Most  of  the  strategies  constructed  on  this  task  are  much  simpler.  Generally,  they  simply 
identify  the  class  of  theorem  and  perform  a  restricted  grind  to  expand  an  appropriate  set 
of  functions.  This  example  shows,  however,  that  more  complicated  strategies  nan  easily  be 
constructed.  See  the  Tools  Report  for  more  details  on  thin  and  other  strat^es. 

The  associated  help  page  for  this  theorem  class  is  as  follows. 

The  current  goal  is  of  the  form  impLinit(oompose(6et),cmp).  The  definition  of 
impLinit  requires  that  any  element  belonging  to  the  init  of  the  first  component, 
compose(set),  is  an  element  of  the  init  of  the  second  component,  cmp.  The  definition 
of  init  for  a  composite  is  the  intersection  of  the  init  for  each  component  composed. 

Thus,  the  first  step  of  the  proof  is  to  reduce  the  goal  to  showing  any  element  be¬ 
longing  to  init  for  every  element  of  set  is  in  init(cmp).  Then,  it  is  necessary  to  show 
that  the  combined  requirements  of  the  inif  s  for  the  elements  of  set  are  sufficient  to 
establish  the  requirements  of  init  for  cmp.  The  strategy  is  aimed  at  automatically 
handling  the  first  step  of  the  proof  Experimentation  with  the  second  step  of  the 
proof  shows  it  is  not  easily  automated,  so  the  default  is  for  the  analyst  to  handle  the 
second  step  himself 

The  everything  flag  controls  whether  the  default  behavior  occurs.  If  set  to  nil,  the 
default  occurs.  Otherwise,  a  grind  command  is  executed  in  an  attempt  to  complete 
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the  proof.  In  experiments  tried,  this  grind  command  can  take  a  long  time  and  still 
fail  to  complete  the  proof 

8.2.2.2  A  More  General  Strategy  The  css  - prove  strategy  provides  focused  help  on  the  recog¬ 
nized  theorem  classes  but  provides  no  help  for  other  types  of  theorems.  To  provide  more  general 
proof  support,  we  defined  a  general  strategy  called  css  -  stewn.  The  PVS  provided  stew  strat¬ 
egy  allows  the  analyst  to  specify  a  set  of  definitions  and  theorems  to  use  in  the  proof  and  then 
makes  use  of  those  hints  to  try  to  automatically  prove  the  theorem.  For  simple  theorems,  this 
strategy  can  be  quite  effective.  However,  for  more  compHcated  theorems,  great  care  must  be 
taken  in  specifying  the  hints.  Generally  the  approach  used  is  to  first  expand  all  definitions  and 
then  try  to  use  logical  operations  to  complete  the  proof  If  too  many  definitions  are  provided  as 
hints,  then  the  strategy  will  expand  much  more  than  it  needs.  Even  with  moderately  complex 
theorems  we  have  seen  stew  take  hours  to  complete.  On  the  other  hand,  if  the  analyst  does  not 
specify  enough  definitions  as  hints,  then  the  strategy  might  not  be  able  to  complete  the  proof 
The  stew  strategy  does  provide  methods  to  fine  tune  the  hints  such  as  si)ecLfying  definitions 
that  should  not  be  expanded,  but  striking  a  proper  balance  can  still  sometimes  be  challenging. 

The  css  -  stewn  strategy  is  simply  a  front-end  to  stew.  It  allows  the  analyst  to  provide  some 
additional  hints  that  are  used  to  fine  tune  the  parameters  provided  to  stew.  The  simplest 
type  of  fine  tuning  enabled  by  css  -  stewn  is  the  specification  of  an  expansion  level.  Specifying 
level  0  results  in  no  definitions  being  expanded  beyond  those  explicitly  hsted  by  the  analyst. 
Specifying  level  1  causes  the  functions  appearing  in  the  current  theorem  to  be  added  to  the 
list.  Specifying  level  2  causes  the  functions  used  in  the  definition  of  the  functions  appearing 
in  the  current  theorem  to  be  added.  In  other  word,  each  time  the  level  is  increased,  function 
expansion  is  done  to  one  level  lower.  This  provides  a  simple  way  for  the  anal3^t  to  prevent 
expansion  from  being  done  too  deeply. 

For  analysts  who  have  knowledge  of  the  internal  representation  of  the  theorem  as  well  as  some 
LISP  programming  experience,  more  advanced  hints  can  be  provided  throtigh  css  -  stewn .  This 
is  accomplished  by  allowing  the  analyst  to  specify  a  LISP  function  defining  a  stopping  criterion 
for  expansion.  This  allows  the  analyst  to  request  functions  be  expanded  until  the  theorem 
has  a  certain  form.  For  example,  the  analyst  could  instruct  the  strategy  to  expand  functions 
until  the  current  goal  is  a  universally  quantified  expression.  As  another  example,  the  analj^t 
could  indicate  that  definitions  should  be  expanded  until  the  current  goal  is  of  the  form  >1  =  5. 
Given  the  need  to  understand  the  internal  structure  of  theorems  and  LISP  programming,  this 
advanced  feature  of  the  strategy  is  expected  to  be  of  use  to  strategy  developers  rather  than 
analysts.  In  fact,  we  expect  the  current  definition  of  css  -  prove  could  be  simplified  by  using 
css-stewn.  Unfortunately,  css-stewn  was  the  last  strategy  we  developed  so  is  not  used  by 
any  of  the  other  work. 


8.3  Accomplishments 

8.3.1  Specification  Brov/ser 

The  Specification  Browser  prototype  implementation  achieved  most  of  its  goals.  It  provides  an 
automated  environment  with  some  flexibility  for  creating  specification  documents  that  follow 
the  CSS  methodology.  Because  ofits  understanding  of  the  high-level  structure  of  a  specification, 
the  Specification  Browser  supports  reviewing  corresponding  formal  specifications  ^nd  text 
descriptions.  The  Specification  Browser  user  interface  shows  an  outline  of  the  specification 
document  based  on  the  required  and  optional  sections  for  use  with  the  composability  ar^d 
refinement  fi’ameworks.  Regular  expression  search  was  implemented  and  the  processing  table 
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tool  was  integrated.  The  template  files  reduce  the  overhead  associated  with  produdng  a 
document.  Since  the  browser  was  implemented  in  Elmacs  LISP  there  is  the  potential  for 
significant  interaction  with  PVS  functionality,  but  this  has  not  been  exploited  in  the  prototype. 

There  are  some  limitations  in  the  browser  functionality: 

■  Configurability  of  section  order  was  only  partially  achieved.  This  turned  out  to  be  a  diffi¬ 
cult  requirement  Currently,  the  formatted  oonunents  which  identify  whole  sections  of  the 
specification  document  can  be  placed  in  any  order  within  a  single  component  specification 
or  transition  file.  However,  the  formatted  comments  are  insufficient  to  connect  a  PVS  file 
to  a  text  section  unless  the  PVS  file’s  formatted  comment  appears  in  that  text  file.  As  a 
result,  if  someone  decided  to  place  all  the  PVS  theories  in  an  appendix,  other  Specification 
Browser  features  such  as  viewing  corresponding  sections,  ffherlring  specification  files,  and 
the  Specification  Browser  outline  interface  would  not  operate  properly. 

■  The  output  of  regular  expression  searches  could  be  more  helpful.  A  regular  expression 
search  can  be  used  from  ffie  Specification  Browser  outline  interface  and  from  any  file  that 
is  part  of  the  current  specification  document  When  a  search  is  performed,  the  results 
are  displayed  in  a  buffer  showing  the  files  and  locations  where  matches  are  found.  This 
buffer  may  be  used  to  move  directly  to  the  buffer  and  the  location  of  the  found  regular 
expression.  The  feature  could  be  improved  if  the  search  results  screen  also  showed  the 
string  found  by  the  regular  expression  search.  Showing  the  line  that  contains  the  found 
regular  expression  might  be  even  more  helpful.  Also,  it  may  be  helpful  to  mark  the  search 
results  after  having  visited  one  of  the  found  regular  expression.  This  would  identify  which 
matches  the  user  has  already  visited. 

■  The  browser  is  probably  of  greatest  help  to  someone  inexperienced  with  the  frramework  and 

with  It  might  not  improve  efficiency  of  someone  who  is  experienced  in  producing 

specification  documents  of  the  type  produced  by  the  browser. 


8.3.2  Analyst’s  Assistant 

The  following  proof  classes  are  currently  recognized  by  css  -prove: 

■  satis fies{.,  always{.)),  where  the  second  parameter  is  an  arbitrary  state  or  action  predi¬ 
cate 

assum.satisfies{.,  always{.)),  where  the  second  parameter  is  a  state  or  action  predicate 

The  strategy  rises  theorems  in  the  fi^amework  to  reduce  these  goals  to  simpler  goals.  The 
analyst  is  expected  to  provide  names  of  lemmas  asserting  these  goals  hold.^^  If  appropri¬ 
ate  lemmas  are  provided  as  hints,  the  proof  is  automatically  completed.  Otherwise,  the 
strategy  displays  what  the  lemmas  should  look  like  and  leaves  the  reduced  goals  for  the 
analyst  to  prove. 

■  steps.saiisfy{.,  stable^.))  or  assuTn.steps.saiisfy{.,  ttable{.)) 

The  strat^y  eiq)ands  the  framework  functions  defining  satisfaction  and  stability  as  well 
as  the  top  level  functions  defining  the  component  and  state  predicate  of  interest.  This 
saves  the  analyst  the  hassle  of  performing  certain  common  steps  that  must  always  be 
performed  for  this  type  of  proof  however,  the  analyst  must  complete  the  proof  manually. 

Actually,  the  atrategy  defaulta  to  using  yarianta  of  the  current  theorem  name  as  the  lemma  names.  By  following  a 
•pe^c  waTTiinp  oonvention,  this  aayes  the  analyst  the  trouble  of  proyiding  the  hints. 
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■  steps.saiisfy{.,  _)  or  assum-steps-saiisfy{., .)  where  the  second  parameter  is  an  arbitrary 
action  pre^cate 

The  strategy  expands  the  framework  functions  defining  satisfaction  as  well  as  the  top- 
level  functions  defining  the  component  «»nd  action  predicate  of  interest.  This  saves  the 
analyst  the  hassle  of  performing  certain  common  steps  that  must  always  be  performed 
for  this  type  of  proof  however,  the  analyst  must  complete  the  proof  manually. 

■  ini<_satts/tes(_, .) 

The  strategy  expands  the  functions  defining  init.sat  is  fits  as  well  as  the  top-level  functions 
defining  the  component  and  state  predicate  of  interest.  The  analyst  must  complete  the 
proof  manually. 

■  init.restriclion{-) 

The  strat^y  reduces  the  goal  to  demonstrating  the  existence  of  a  state  satisfying  the 
init  for  the  component  of  interest.  The  analyst  can  optionally  provide  as  a  hint  a  lemma 
asserting  the  existence  of  such  an  element.  The  proof  is  completed  automatically  if  the 
hint  is  provided. 

■  cags.restriction{.) 

The  strategy  reduces  the  goal  to  demonstrating  the  existence  of  an  agent  satisfying  the 
cags  for  the  component  of  interest.  The  analyst  can  optionally  provide  as  a  hint  an  element 
believed  to  be  in  cags.  If  the  hint  is  provided  the  FVS  provided  grind  strat^y  is  used  to 
attempt  to  complete  the  proof  by  showing  the  specified  element  is  in  cags.  Our  experience 
is  that  when  the  hint  is  provided  the  proof  can  typically  be  completed  automatically. 

•  guarjresiriclion{.),  rely.resirictioTi{J),  hiddjresiriclion{.),  view.rely-restriction^.), 
viewJiiddjrestriclion{J),  vicw^uarj’cstridioni^J),  viewjinit-restriction{J), 
view.wf arjrestriction{^),  viewjf ar.restridion^.),  g'uaraiutieringjrestriction{J), 
rely. stuttering. restricti(m{.),  hiddMutteringjrestriction{.\  wfarjrestriction{.), 
sfar.restricti(m{.),  wfarMutteringjrestriction{.),  or  sfar stuttering. restriction{.) 

The  strategy  expands  the  functions  defining  the  restriction  of  interest  as  well  as  top-level 
functions  defining  the  component  of  interest  In  some  cases,  this  is  sufficient  to  complete 
the  proof  Generally,  though,  additional  functions  need  to  be  expanded  to  complete  the 
proof  These  additional  functions  can  be  provided  as  hints  to  the  strategy.  Then,  the  proof 
is  completed  automatically.  The  functions  that  mxist  be  provided  as  hints  are  usually 
straight-forward  to  determine  finm  the  structure  of  the  specification.^^ 

■  compJ{.) 

The  strategy  expands  compJt.  This  reduces  the  goal  to  showing  each  of  the  component 
restrictions  holds.  Since  the  component  restriction  theorem  classes  were  addressed  above 
(see  the  preceding  three  bullets),  this  theorem  class  will  not  be  discussed  further  here. 

■  VIEWSivw) 

The  strategy  simply  executes  the  grind  strat^iy.  Due  to  the  way  in  which  CSS  specifica¬ 
tions  are  written,  this  was  found  to  always  complete  the  proof  automatically 

■  tnit  (-)(-) 

The  strategy  simply  executes  the  grind  strategy.  With  the  CSS  si>ecLfications,  this  was 
always  found  to  automatically  complete  the  proof 

An  obrious  enhancement  woiild  be  to  have  the  etrategy  identify  these  ftmetiona  automatically. 
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■  impLtnit{compose{S^yJ) 

This  theorem  class  was  used  in  the  previotis  section  to  illustrate  the  strategy  develop¬ 
ment  process.  The  strategy  reduces  the  goal  by  e3q>anding  framework  functions  and  the 
definition  of  inii  for  the  composite,  but  the  analyst  must  complete  the  proof  manually. 

■  su6sc< ?(^uar( compose (_)),  ptxar(.))  or  subsei?{kidd{compose{^))j  hidd{J)) 

The  strategy  operates  on  these  classes  in  a  manner  analogous  to  that  for  impLinii. 
m  impLsteps{compo8e{^)y .)  or  tmp/cmcnts(-,.) 

The  strategy  expands  tmpLsteps  or  implements  to  reduce  the  goal  to  demonstrating  pre¬ 
viously  described  theorem  classes.  The  analyst  can  then  invoke  the  strategy  again  to 
work  on  each  of  the  generated  goals.  Alternatively,  the  analyst  provide  lemma  names 
addressing  the  generated  goals  in  which  case  the  proof  is  complete  automatically.  The 
strategy  defaults  to  trying  variants  of  the  theorem’s  name  as  the  lemma  names.  If  the 
analjrst  follows  certain  naming  conventions  this  allows  the  proof  to  be  automatically  com¬ 
pleted  even  without  explicitly  providing  the  hints. 

Most  of  the  practical  experience  with  the  strategies  developed  on  this  task  was  with  the  strate¬ 
gies  fidmed  at  proving  a  candidate  component  specification  satisfied  the  requirements  on  com¬ 
ponents.  Each  component  specified  had  18  lemmas  specified  and  one  TCC  generated  that  dealt 
with  these  requirements.  Since  10  or  so  components  were  specified  on  the  program,  this  gave 
around  200  lemmas  with  which  to  experiment.  The  set  of  theorems  stated  about  compositions 
and  refinements  was  much  smaller  so  less  experimentation  was  possible. 

Generally,  the  strategy  was  found  to  be  quite  effective  on  the  component  restriction  theorem 
classes.  With  minimal  hints  provided  by  the  analyst,  the  strategy  was  able  to  automatically 
prove  all  but  two  of  the  approximately  200  tests  run.  Use  of  dependent  typing  in  the  specifica¬ 
tions  was  the  caiise  of  the  other  two  tests  failing.  Althoxigh  the  strategy  could  not  complete  the 
proofs  automatically,  it  still  made  significant  progress  on  the  proofs. 

For  the  other  classes  of  theorems,  too  few  examples  were  worked  to  make  a  meaningful  assess¬ 
ment  For  simple  theorems  such  as  showing  that  view  relations  are  equivalence  relations  and 
showing  that  given  witness  states  are  elements  of  iniiy  css  -prove  was  found  to  (juickly  wnH 
automatically  complete  proofs  in  the  examples  tried.  For  more  complicated  theorems  such  as 
showing  impLinit{compose{8€t),  emp)  holds,  the  strategy  was  found  to  reduce  the  theorem  to  the 
desired  point.  Once  the  general  approach  for  defining  strategies  was  developed,  strategies  for 
new  classes  of  theorems  could  tisually  be  defined  within  an  hour  or  two  of  time.  This  suggests 
that  with  a  minimal  amount  of  additional  time  the  css  -prove  strategy  could  be  extended  to 
cover  additional  classes  of  theorems  that  arise  when  using  the  CSS  framework. 

In  addition  to  the  strategies  themselves,  we  also  documented  instructions  on  how  to  write  FVS 
proof  strategies.  The  intent  is  that  this  information  would  provide  a  starting  point  for  others 
who  wish  to  modify  our  stxat^es  or  write  their  own. 

8.4  Lessons 

8.4.1  Specification  Browser 

The  following  lessons  have  been  drawn  from  the  Specification  Browser  work: 

■  Configurability  in  the  order  of  sections  —  The  requirement  to  allow  configurability 
in  the  order  of  specification  document  sections  increased  the  complexity  of  most  features 
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of  the  Spedfication  Browser.  More  work  would  have  been  completed  on  this  first  prototype 
if  this  requirement  had  been  omitted. 

■  Degree  of  control  over  specification  document  —  It  is  easy  for  a  writer  to  bypass 
the  Spedfication  Browser  and  develop  spedfication  documents  that  do  not  follow  the 
format  produced  by  the  browser.  This  would  seriously  undermine  the  ability  of  the  tool 
to  fiilfiU  its  function.  Preventing  specifiers  fiiom  bypassing  tha  Si>ecification  Browser 
would  require  a  more  sophisticated  implementation  than  could  be  developed  under  this 
prototype  effort.  It  would  be  necessary  either  to  place  the  structural  information  (i.e., 
the  formatted  comments)  maintained  by  the  tool  outside  the  text  files  themselves  or  to 
elevate  them  to  commands  that  must  be  properly  maintained  by  the  specifier  and  parsed 
for  the  dociunent  to  be  considered  weU-formed  iiq>ut  to  the  tool. 

•  Low-level  versus  hi^-level  view  of  structure — The  Specification  Browser  interface 
was  initially  conceived  at  a  rather  low  level  in  which  Emacs  M-x  commands  were  entered 
to  instantiate  template  files  and  link  them  together.  It  was  subsequently  decided  that  a 
higher-level,  outline-oriented  interface  would  be  more  user  Mendly.  The  tool  might  have 
turned  out  better  had  we  started  thinking  about  the  outline-oiiented  interface  earlier. 


8.4.2  Analyst’s  Assistant 

The  work  resulted  in  the  following  observations: 

■  PVS  strategies  provide  an  effective  mechanism  for  providing  help  to  analysts.  They  are 
simple  enough  to  write  that  the  amount  of  time  they  save  anal3rstE  justifies  the  investment 
to  construct  them. 

■  Strategies  provide  a  useful  bridge  between  how  one  would  like  to  write  spedficationE  and 
how  one  is  sometimes  forced  to  write  specifications.  For  example,  consider  the  theorem 
class  impLinit{compose{.), .).  The  part  of  the  proof  addressed  by  css  -prove  is  rewriting 
init{coTnpose{.))  as  init{cmpi )  A  ...  A  inU{cmpn ).  This  rewiiti^  would  not  be  necessary 
if  the  compose  operator  would  e^lidtly  set  init  to  the  coigunction  of  the  inits  for  the 
individual  components.  This  is  not  possible,  though,  since  the  number  of  components 
is  unknown.  Instead,  a  tiniversally  quantified  expression  is  used  to  assert  the  result 
incorporates  each  component  init.  Because  the  proof  strategy  is  executed  at  proof  time 
when  the  number  of  components  being  composed  is  known,  it  can  rewrite  the  expression 
in  the  more  useful  form. 

As  another  example,  the  standard  approach  for  writing  CSS  components  is  to  first  spec¬ 
ify  sptcJbase,  then  demonstrate  specJbase  satisfies  the  component  restrictions,  wild  finally 
spedfy  spec  to  be  equal  to  specJbase.  This  is  necessary  to  allow  FVS  to  successfully 
typecheck  the  theorems  asserting  the  candidate  comxwnent  satisfies  the  component  re¬ 
strictions,  but  is  annoying  when  proviog  other  theorems  since  it  is  necessary  to  expand 
both  spec  and  specJbase  rather  than  simply  expanding  spec.  The  strategies  can  hide  the  ad¬ 
ditional  layer  of  specification  by  automatically  expanding  specJbase  whenever  «»ifr”"dir>g 
spec. 

m  Due  to  the  nature  of  this  task,  little  thought  was  given  to  building  blocks  that  would  be 
of  use  in  writiing  strategies.  New  functions  were  defined  as  needed  to  address  the  next 
class  of  theorem  to  be  recognized  by  the  strategy.  Future  strategy  development  would 
benefit  from  having  a  set  of  general  purpose  utilities  upon  which  to  build.  For  example, 
as  mentioned  earlier  the  css-stewn  strategy  could  provide  a  powerful  building  block 
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for  use  in  other  stmtegies.  In  addition  to  simplifying  the  implementation  of  the  existing 
strategies,  this  could  simpliiy  the  construction  of  strategies  in  the  future. 

■  The  effectiveness  of  stiategdes  is  heavily  dependent  on  the  structure  of  the  spedfications. 
For  example,  some  stiategies  that  worked  well  on  CSS  specifications  were  found  to  work 
poorly  on  strategies  written  in  a  different  form  on  another  project.  One  way  to  view 
this  lesson  is  that  analysts  should  write  their  specifications  in  a  standard  format  for 
which  their  proof  strategies  are  tuned. ^  Another  way  to  view  this  lesson  is  that  the 
more  specifications  that  can  be  used  to  test  a  strategy  the  better.  Experience  gained 
from  additional  testing  might  allow  the  strategy  to  be  made  more  tolerant  of  differing 
specification  styles. 

■  A  trade-off  must  often  be  made  between  the  number  of  steps  automatically  executed  by 
the  strategy  and  the  complexity  of  the  goals  left  for  the  analyst  to  prove.  For  example, 
each  strategy  could  finish  by  attempting  a  grind,  but  for  more  complicated  theorems 
this  would  take  a  long  time  and  leave  the  analyst  with  a  large  number  of  goals  to  prove. 
Making  this  trade-off  is  somewhat  subjective  was  difficult  to  do  on  this  effort  due  to 
the  small  number  of  examples  worked. 


8.5  Future  Work 

8.5.1  Specification  Browser 

The  following  are  some  of  the  areas  for  future  work  on  the  Specification  Browser: 

■  HTML  output  —  Post  script  viewers  are  not  readily  available  on  all  computing  platforms. 
Conversion  of  the  to  HTML  is  suggested  because  web  browsers  (HTML  viewers) 
are  available  on  most  computing  platforms  at  no  cost.  HTML  output  could  allow  people 
to  participate  in  document  reviews  more  easily. 

■  Automatic  File  Creation  —  The  Specification  Browser  is  not  completely  automatic 
when  it  comes  to  creating  and  linking  parts  of  a  specification  document  while  viewing 
the  *TLS  OUTLINE*  buffer,  the  Specification  Browser  outline  interface.  Three  com¬ 
mands,  tls-add-comp-spec,  tis-add-transition,  and  tls-add-prooessing-table,  only  provide 
instructions  on  actions  required  to  add  parts  to  a  specification  document. 

The  problem  of  determining  where  to  position  new  parts  of  a  specification  document  was 
more  difficult  than  expected.  Consider  creating  and  adding  a  component  specification.  If 
the  *TLS  OUTLINE*  buffer  is  displaying  a  document  outline  only  detailed  to  the  level  of 
showing  other  component  specifications,  then  it  is  fairly  easy,  based  on  the  cursor  position, 
where  the  newly  created  component  specification  should  be  placed. 

If  the  *TLS  OUTLINE*  buffer  is  displaying  a  document  outline  which  shows  all  the  details 
of  a  document  outline,  the  cursor  position  does  not  always  deariy  identify  the  position  for 
the  new  component  specification.  When  the  cursor  is  immediately  before  or  after  the  start 
or  end  of  a  component  specification,  the  position  of  the  new  component  specification  win 
be  determined.  A  set  of  rules  is  needed  to  guide  the  Specification  Browser  in  positioning 
a  new  component  specification  when  the  cursor  is  in  a  low-level  section  of  an  existing 
component  specification 

If  tls-add-comp-spec,  tls-add-transition,  and  tls-add-prooessing-table  were  modified  to 
more  fuUy  automate  the  process  of  creating  and  linking  parts  of  a  specification  document, 
the  Specification  Browser  would  be  a  more  user-friendly  tool. 

^^U«en  of  the  css  -prove  strategy  should  shrive  to  write  speafications  is  the  form  used  for  the  CSS  specifications. 
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■  Request  Transition  State  Changes  —  At  several  levels  in  a  specification  document 
a  sequence  of  related  sections  is  allowed.  For  example,  the  entire  document  can  consist 
of  a  sequence  of  component  specifications;  each  component  spedfication  can  contain  a 
sequence  of  request  specifications;  and  each  request  specification  can  contain  a  sequence 
of  transitions  that  describe  the  various  processing  cases.  Due  to  lack  of  time  this  last 
example  not  been  fully  integrated  into  the  tool.  If  it  were  added  it  would  be  desirable  to 
also  implement  functionality  to  cherk  consistency  between  the  transition  sections  included 
and  the  rows  of  the  processing  table. 

8.5.2  Analysts  Assistant 

Areas  in  which  additional  work  could  be  done  indude: 

■  Building  a  larger  set  of  specifications  to  use  as  a  testbed.  This  would  provide  data 
regarding  the  robustness  of  the  strategies. 

■  Constructing  general  purpose  strategies  that  could  be  used  as  building  blocks  for  other 
strategies.  Essentially,  this  would  result  in  a  strategy  development  kit  (SDK).  Rewriting 
the  existing  strategies  with  such  an  SDK  would  make  them  more  maintainable.  In 
addition,  future  strategies  could  be  constructed  more  easily. 

■  Improving  how  the  css  -  prove  strategy  handles  the  currently  recognized  classes  of  theo¬ 
rems.  For  example,  to  prove  component  restrictions  using  css  -  prove  currently  requires 
the  analyst  provide  hints.  Some  of  these  hints  could  be  guessed  at  by  the  strategy.  This 
would  make  the  proofs  slightly  more  automated. 

■  Expanding  the  set  of  classes  recognized  by  the  css -prove  strategy.  This  would  expand 
the  scope  of  the  help  provided  to  analysts. 
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Section  ^ 

^ogram  Conclusions 


This  report  has  provided  an  overview  of  the  work  performed,  accomplishments  and  lessons 
learned  on  the  Composability  for  Secure  Systems  program.  A  PVS  framework  for  compo¬ 
sition  ftTid  refinement  reasoning  has  been  developed.  The  application  of  this  framework  to 
the  analysis  of  functional  correctness,  design  refinement,  fault  tolerance  and  security  has  been 
demonstrated.  We  have  also  explored  the  use  of  tools  to  make  this  analysis  easier  and  more  cost 
effective.  Questions  remaining  for  future  work  are  outlined  in  each  of  the  foregoing  sections. 
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